Mastering Flash Sale Scalability: Redis, MQ, and Inventory Hint Strategies

In the fiercely competitive e‑commerce arena, flash‑sale events generate massive traffic spikes that can overwhelm a single database table, requiring robust high‑concurrency solutions.

1 Industry Common Practices

1.1 Pressure Distribution

Bucket‑based pressure distribution splits a product’s inventory into multiple groups to alleviate peak load, but it raises challenges such as even bucket allocation, fragment handling, dynamic scaling, and coordination rules.

1.2 Redis+MQ

Redis provides high‑performance reads/writes and atomic operations to prevent overselling, while MQ buffers and throttles burst traffic, smoothing the load on downstream storage.

Although Redis is powerful, a pure‑Redis flow would miss later steps such as order confirmation and payment, which require real‑time data consistency.

1.3 Inventory Hint

Some companies directly operate the database using Alibaba Cloud RDS equipped with the Inventory Hint technology, which optimizes hot‑row updates and maintains stability under high concurrency.

1.4 Pressure Distribution + Redis + MQ

For millions of QPS, a combination of SQL batch execution, distributed and local caches, and bucket‑based traffic splitting works together to share load and keep large‑scale promotions stable.

2 Redis + MQ for Flash‑Sale Scenarios

2.1 Redis Stock Pre‑Deduction

The solution uses a Redis Lua script to atomically deduct stock, ensuring consistency and efficiency. Example code:

<code>/*
 * KEYS[1] --商品id
 * KEYS[2] --用户id uid
 * ARGV[1] --扣减数量
 * ARGV[2] --用户提交的  token
 */
String luaScript = "redis.replicate_commands()\n"
        + "if redis.call('hexists', KEYS[2], ARGV[2]) == 1 then\n"
        + "return redis.error_reply('repeat submit')\n"
        + "end \n"
        + "local product_id = KEYS[1] \n"
        + "local stock = redis.call('get', KEYS[1]) \n"
        + "if tonumber(stock) < tonumber(ARGV[1]) then \n"
        + "return redis.error_reply('stock is not enough') \n"
        + "end \n"
        + "local remaining_stock = tonumber(stock) - tonumber(ARGV[1]) \n"
        + "redis.call('set', KEYS[1], tostring(remaining_stock)) \n"
        + "local time = redis.call('time') \n"
        + "local currentTimeMillis = (time[1] * 1000) + math.floor(time[2] / 1000) \n"
        + "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})\n"
        + "return remaining_stock";
</code>

2.1.1 Lua Script Execution Flow

The script uses a hash to store per‑user tokens and a string key for product stock.

2.1.2 Main Actions of the Script

Prevent duplicate submissions by checking a token.

Verify stock sufficiency and atomically deduct the requested amount.

Record a transaction log in a hash for later consistency checks.

2.2 MySQL Stock Deduction

MySQL deduction is performed via RocketMQ transactional messages to guarantee atomicity:

Send a half‑message; consumption is paused until the local transaction result is known.

Check the local transaction by confirming the Redis Lua script succeeded; commit or roll back accordingly.

RocketMQ’s message‑check mechanism ensures the log exists before committing.

Consume the message, deduct MySQL stock, and record the operation log, relying on MQ retry to maintain consistency.

2.3 Reason for Recording Operation Logs

Logs enable reconciliation between inventory and order tables; alternatives such as Seata or TCC can also provide distributed transaction guarantees.

3 Inventory Hint Database Deduction

3.1 Usage

Applying the Inventory Hint hint to an SQL statement on Alibaba Cloud RDS activates the optimization.

3.2 Principle

The technique optimizes hot‑row updates by grouping updates with the same primary or unique key, reducing row‑level lock wait time, B‑tree index traversal, and transaction commit frequency. Two execution units alternate to collect and submit grouped updates in parallel.

Key Optimizations

Reduce row‑lock acquisition latency by leader‑follower coordination.

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

Decrease transaction commit count by committing grouped updates in a single transaction.

4 Summary

Solution selection depends on traffic volume: low concurrency can rely on a single locked table; moderate spikes benefit from Redis + MQ; massive scale requires pressure distribution, Redis + MQ, and Inventory Hint to fully exploit database potential.