Handling Overselling in High‑Concurrency Scenarios: Pessimistic, FIFO, and Optimistic Lock Strategies

When multiple threads write to the same file, thread‑safety problems arise; MySQL's built‑in lock can solve this for small loads but is not recommended for large‑scale concurrency such as flash‑sale or抢购 scenarios, where overselling (selling more items than available) becomes a critical risk.

1. Reason for overselling If only 100 items are available and 99 have been sold, a sudden burst of concurrent requests may all read the remaining stock as 99, each passing the check and causing the system to sell more than the actual inventory.

2. Pessimistic lock approach Pessimistic locking locks the data during modification, forcing other requests to wait. In high‑concurrency environments this leads to lock contention, long response times, and exhausted connections, ultimately degrading system availability.

3. FIFO queue approach Placing incoming requests into a First‑In‑First‑Out queue avoids lock starvation, but under massive traffic the queue can quickly exhaust memory, causing the system to become unstable or crash.

4. Optimistic lock approach Optimistic locking uses a version number for each data item; a request succeeds only if the version it read matches the current version, otherwise it fails. This reduces the need for queues and locks, though it adds some CPU overhead, and is generally considered a balanced solution.

Many software and services provide optimistic‑lock capabilities, such as Redis's WATCH command, which can be used to ensure data safety in high‑concurrency purchase systems.