Concurrent Queue Selection and High-Concurrency Design for Flash Sale Systems

Java's concurrency package provides three commonly used concurrent queue implementations: ArrayBlockingQueue, ConcurrentLinkedQueue, and LinkedBlockingQueue.

ArrayBlockingQueue is a blocking queue with a fixed initial capacity, suitable for scenarios like a database module's successful bidding queue; for example, with ten products we can set an array queue of size ten.

ConcurrentLinkedQueue uses a lock‑free CAS implementation, offering fast enqueuing but slower dequeuing due to locking.

LinkedBlockingQueue is also a blocking queue; both enqueue and dequeue operations acquire locks, and threads block when the queue is empty.

During request preprocessing, because enqueue demand far exceeds dequeue demand and the queue rarely becomes empty, we can choose ConcurrentLinkedQueue as the request‑queue implementation.

Reasonable Design of Request Interfaces

A flash‑sale or抢购 page typically consists of two parts: static HTML content delivered via CDN, and the backend request interface that participates in the sale.

The static part imposes little pressure; the real bottleneck is the backend interface, which must handle high concurrency and respond as quickly as possible. To achieve speed, backend storage should use in‑memory operations; direct access to MySQL is unsuitable, and for complex business logic asynchronous writes are recommended.

Some flash‑sale implementations use “delayed feedback,” where the result is shown later; this lazy approach harms user experience and may be perceived as opaque.

Data Safety Under High Concurrency

When multiple threads write to the same file, thread‑safety issues arise. MySQL's built‑in locking can solve this, but it is not recommended for massive concurrency. In flash‑sale scenarios another problem is “overselling,” where more orders are accepted than available stock, often due to technical issues rather than malicious merchants.

Causes of Overselling

Assume a product has 100 units and only one remains. Simultaneous requests read the remaining count as 99, all pass the check, and multiple users end up purchasing the last item, causing overselling.

In high‑concurrency situations this scenario is common.

Pessimistic Lock Approach

Pessimistic locking locks data during modification, forcing other requests to wait.

While this solves thread‑safety, in high‑concurrency environments many requests would block, potentially exhausting connections and degrading performance.

FIFO Queue Approach

By placing requests into a FIFO queue, we avoid starvation, but the queue may grow beyond memory limits under massive load, leading to system overload.

Optimistic Lock Approach

Optimistic locking uses version numbers; each request carries a version, and only updates succeed when the version matches, otherwise the request fails. This reduces lock contention but adds CPU overhead, offering a balanced solution.

Many software and services support optimistic locking, such as Redis's WATCH command, which helps ensure data safety.

(End)