How to Master High‑Concurrency Flash‑Sale Systems with Redis, MQ, and Inventory Hint

Background

Flash‑sale (秒杀) events generate bursty traffic that can overwhelm a single MySQL table. Low concurrency can be handled with simple row locking, but popular items may receive millions of requests per second, requiring a robust anti‑pressure stack.

1. Common Industry Practices

1.1 Pressure Distribution (Bucket Strategy)

Requests are split into multiple buckets to spread load. Key challenges include even inventory allocation, handling fragmented stock, dynamic bucket scaling, and coordinated bucket scheduling.

1.2 Redis + Message Queue (MQ)

Redis provides fast, atomic operations to prevent overselling, while an MQ buffers spikes and smooths downstream database load. The combination ensures real‑time stock checks and reliable asynchronous persistence.

1.3 Inventory Hint (Alibaba Cloud RDS)

The proprietary Inventory Hint feature optimizes hot‑row updates at the MySQL engine level, reducing lock contention and index traversal.

1.4 Combined Approach (Bucket + Redis + MQ)

For extreme QPS, a layered solution merges bucket distribution, Redis caching, and MQ buffering, allowing each component to handle a portion of the load.

2. Redis + MQ Detailed Implementation

2.1 Redis Stock Pre‑Deduction with Lua

The Lua script guarantees atomicity and performs three main steps:

Prevent duplicate submissions using a token stored in a hash.

Check stock availability and decrement it atomically.

Record a transaction log in a hash for later reconciliation.

/*
 * KEYS[1] -- product id
 * KEYS[2] -- user id (uid)
 * ARGV[1] -- quantity to deduct
 * ARGV[2] -- submission token
 */
String luaScript =
"redis.replicate_commands()
" +
"if redis.call('hexists', KEYS[2], ARGV[2]) == 1 then
" +
"return redis.error_reply('repeat submit')
" +
"end 
" +
"local product_id = KEYS[1] 
" +
"local stock = redis.call('get', KEYS[1]) 
" +
"if tonumber(stock) < tonumber(ARGV[1]) then 
" +
"return redis.error_reply('stock is not enough') 
" +
"end 
" +
"local remaining_stock = tonumber(stock) - tonumber(ARGV[1]) 
" +
"redis.call('set', KEYS[1], tostring(remaining_stock)) 
" +
"local time = redis.call('time') 
" +
"local currentTimeMillis = (time[1] * 1000) + math.floor(time[2] / 1000) 
" +
"redis.call('hset', KEYS[2], ARGV[2], cjson.encode({action='扣减库存', product=product_id, from=stock, to=remaining_stock, change=ARGV[1], token=ARGV[2], timestamp=currentTimeMillis}))
" +
"return remaining_stock";

2.1.1 Lua Execution Flow

The script uses two Redis data structures:

Hash (outer key KEYS[2], inner key ARGV[2]) stores a JSON log for each user token.

String (key KEYS[1]) holds the current stock count for the product.

2.2 MySQL Stock Deduction via RocketMQ Transaction Messages

To keep MySQL consistent, the system sends a half‑message to RocketMQ, executes the Redis Lua script, and commits or rolls back based on the script result. The workflow:

Send a RocketMQ half‑message (not consumable yet).

Execute the Redis Lua script; if successful, return COMMIT, otherwise ROLL_BACK.

RocketMQ may perform a message check; the presence of a log entry confirms commit eligibility.

When the consumer processes the message, it updates MySQL stock and acknowledges only after the database write succeeds.

2.3 Reason for Recording Operation Logs

Logs enable reconciliation between the stock log and the order table, allowing detection of missing orders and manual intervention. Alternative consistency solutions such as Seata or TCC can be used depending on business requirements.

3. Inventory Hint Database Deduction

3.1 Usage

Applying Inventory Hint involves adding a special hint clause to the SQL statement, as described in Alibaba Cloud documentation.

3.2 Principle

The hint marks the update as a hot‑row operation. MySQL groups updates to the same primary or unique key, processes them in batches, and reduces row‑level lock wait time, B‑tree index traversal, and transaction commit frequency.

3.3 Key Optimizations

Reduced row‑lock acquisition latency by allowing follower threads to skip lock acquisition when the leader already holds the lock.

Minimized B‑tree index scans by caching the first row and updating subsequent rows directly from cache.

Fewer transaction commits by grouping multiple updates into a single batch commit.

4. Solution Selection Guidance

Choose the appropriate combination based on traffic volume:

Low concurrency: Single‑table locking is sufficient.

Moderate concurrency: Combine Redis for fast stock checks with MQ for buffering.

Extreme concurrency: Add pressure‑distribution buckets and, if needed, leverage Inventory Hint to push more work into the database engine.

Proper tuning of these components ensures flash‑sale systems remain reliable, avoid overselling, and maintain high performance.