It was 1 AM when the ops girl ripped me out of a dream with a phone call: “The flash sale page went completely white as soon as we launched!” I opened the monitoring dashboard and saw the database connection pool had burst, CPU was pegged at 95%, only 37 coupons had been issued, yet inventory still showed over 2000 remaining — overselling wasn’t prevented, and the service crashed first. Classic “the hotter the event, the more embarrassing the system.”

Breaking down the problem

We were running an “on-the-hour” flash sale with 10,000 coupons, hyped for two straight days. The moment it went live, we were hit with roughly 80,000 QPS instantly. The original design was dead simple: when a request arrived, check the stock field in the database; if stock > 0, execute UPDATE ... SET stock = stock - 1, then insert a claim record. Under concurrency, this completely fell apart — two requests simultaneously read stock = 5, both decided they could deduct, and we ended up issuing 6 coupons. Overselling by 1. Even worse, row locks and deadlocks dragged the entire database instance into the ground.

In plain terms, there were two root causes: the “read-check-write” sequence is not atomic, and disk + row locks can’t survive high concurrency. Optimistic locking with a version column fixes overselling, but at tens of thousands of QPS, the flood of conflict retries would still slam MySQL’s CPU to 100%. That’s treating a symptom. Serializing requests through a message queue prevents overselling too, but the real‑time feedback is gone — users wait several seconds for a result, and the experience tanks. We needed a solution that could atomically handle “check + deduct” and withstand memory‑speed reads and writes.

Designing the solution

The answer came almost instinctively: Redis + Lua scripts.

Why not Redis transactions (MULTI/EXEC)? Because transactions lack conditional logic — you can’t do if stock > 0 inside one. You have to bundle the check and the decrement into a single atomic block, and Lua scripts are natively atomic. Why not Redis distributed locks? The granularity would be too coarse. With thousands of coupons, there’s no reason for all requests to fight for a single lock and queue up — that turns parallelism into serialization and destroys throughput.

The architecture is straightforward: store coupon inventory in Redis (a single key), and use a Lua script to pack the three steps — “check stock → decrement stock → record the user’s claim” — into a single command sent to Redis. One network round‑trip, executed atomically. The backend simply calls this script and checks the return value to determine the result. The entire operation dropped from tens of milliseconds (with database lock contention) to sub‑millisecond, and a single Redis instance easily absorbed tens of thousands of QPS.

Core implementation

Here’s a runnable Python snippet that simulates the flash sale entry point, giving you a clear picture of the overall flow. It solves the problem of calling a Redis Lua script from the backend to complete a single coupon grab.

import redis
import hashlib
import time

# 连接 Redis
r = redis.Redis(host='localhost', port=6379, decode_responses=True)

# 把 Lua 脚本加载进来，避免每次 EVAL 传输脚本内容（用 EVALSHA 更省带宽）
LUA_SCRIPT = """
-- KEYS[1]: 库存 key, 例如 "coupon:stock:1001"
-- KEYS[2]: 用户领取集合 key, 例如 "coupon:users:1001"
-- ARGV[1]: 用户ID
-- ARGV[2]: 限制每人领取数量，默认1
local stock_key = KEYS[1]
local users_key = KEYS[2]
local user_id = ARGV[1]
local limit = tonumber(ARGV[2]) or 1

-- 1. 检查用户是否已达领取上限
local user_count = redis.call('SCARD', users_key)
-- 如果已经领取的数量 >= 限制，返回 -1 表示已抢过
if redis.call('SISMEMBER', users_key, user_id) == 1 then
    return -1
end

-- 2. 检查库存
local stock = tonumber(redis.call('GET', stock_key) or "0")
if stock <= 0 then
    return 0  -- 库存不足
end

-- 3. 扣减库存并记录用户
redis.call('DECR', stock_key)
redis.call('SADD', users_key, user_id)
return 1  -- 抢券成功
"""

# 预加载脚本，拿到 SHA 值
sha = r.script_load(LUA_SCRIPT)

def grab_coupon(coupon_id, user_id, per_user_limit=1):
    """
    返回: 1 成功, 0 库存不足, -1 已抢过
    """
    try:
        # 优先用 EVALSHA，失败时用 EVAL 兜底
        result = r.evalsha(sha, 2,
                           f"coupon:stock:{coupon_id}",
                           f"coupon:users:{coupon_id}",
                           user_id, per_user_limit)
        return result
    except redis.exceptions.NoScriptError:
        # 如果脚本被 Redis 重启清除了，重新加载并重试一次
        sha = r.script_load(LUA_SCRIPT)
        return r.evalsha(sha, 2,
                         f"coupon:stock:{coupon_id}",
                         f"coupon:users:{coupon_id}",
                         user_id, per_user_limit)

if __name__ == '__main__':
    # 初始化库存（仅演示，实际应在活动开始前设置）
    r.set("coupon:stock:1001", 1000)
    r.delete("coupon:users:1001")

    print(grab_coupon(1001, "user_1"))  # 1 成功
    print(grab_coupon(1001, "user_1"))  # -1 已抢过
    print(grab_coupon(1001, "user_2"))  # 1 成功
    print(r.get("coupon:stock:1001"))   # 998

The Lua logic is the heart of the whole solution: everything runs in Redis’s single‑threaded execution, making it naturally atomic. Stock is decremented directly with DECR — no read‑then‑write race. User deduplication uses a Set, and SISMEMBER is O(1). This approach elegantly prevents overselling and duplicate claims.