秒杀系统的数据库架构设计：热点隔离、库存扣减与异步排队的铁三角
一、100万人抢1000台手机，数据库连接池瞬间打满
秒杀是对数据库最极端的压力测试。当100万用户在同一秒钟点击"抢购"按钮时，1000台手机的库存要在这100万请求中原子扣减且不能超卖。传统做法是直接在MySQL中UPDATE stock SET count=count-1 WHERE id=12345 AND count>0——在1000QPS下工作良好，但在10万QPS下连接池迅速耗尽，大量请求排队等待锁释放，最终超时告终。
秒杀场景的独特挑战在于"热点集中"——100%的请求都打在同一个SKU的同一行库存记录上。在InnoDB中，这行数据被频繁加锁和修改，行锁争抢导致大量线程在等待，CPU花在锁调度上而非实际处理业务。当等待队列超过innodb_thread_concurrency限制时，新请求被拒绝——这就是秒杀期间大量用户看到"系统繁忙"的根因。
二、秒杀数据库的三层解耦：热点缓存、事务排队与最终一致
第一层：网关限流。前端的100万并发本质上不可能也不需要在数据库层处理。网关层使用令牌桶算法将流入量控制在10万QPS以内——即使Redis处理能力远超这个值，也不能让更多的请求进入内层，因为后端MySQL的消费能力是固定的（约1000 QPS）。
第二层：Redis原子库存扣减。使用Lua脚本实现检查库存+扣减的原子操作，单分片Redis轻松支持10万QPS。扣减成功后生成一个唯一Token返回给用户，同时将扣减事件推入Redis List作为排队队列。用户拿到Token后进入"排队中"状态。
第三层：异步消费落库。后端消费者以固定速率（如1000/s）从Redis队列中消费扣减事件，逐个写入MySQL并创建订单。这个消费速率由MySQL的写入能力决定，不能超过它。消费者单线程处理消除了MySQL行锁争抢。
三、基于Redis Lua的原子库存扣减实现
-- lua/stock_deduct.lua -- Redis Lua脚本：原子库存扣减+生成排队Token -- KEYS[1]: stock_key (库存Key) -- KEYS[2]: queue_key (排队队列Key) -- ARGV[1]: user_id -- ARGV[2]: request_id (幂等Key) -- ARGV[3]: max_per_user (每用户限购数量) local stock_key = KEYS[1] local queue_key = KEYS[2] local user_id = ARGV[1] local request_id = ARGV[2] local max_per_user = tonumber(ARGV[3]) or 1 -- 幂等性检查 local idempotent_key = 'seckill:idempotent:' .. request_id if redis.call('EXISTS', idempotent_key) == 1 then return {0, 'duplicate_request', request_id} end -- 用户限购检查 local user_bought_key = 'seckill:user_bought:' .. user_id local user_bought = tonumber(redis.call('GET', user_bought_key)) or 0 if user_bought >= max_per_user then return {0, 'user_limit_exceeded', user_id} end -- 库存检查与扣减 local stock = tonumber(redis.call('GET', stock_key)) or 0 if stock <= 0 then return {0, 'sold_out', 0} end -- 扣减库存 local remaining = redis.call('DECR', stock_key) if remaining < 0 then -- 超卖回滚 redis.call('INCR', stock_key) return {0, 'sold_out', 0} end -- 标记幂等（60秒过期，防止重复请求） redis.call('SETEX', idempotent_key, 60, '1') -- 更新用户购买计数 redis.call('INCR', user_bought_key) redis.call('EXPIRE', user_bought_key, 86400) -- 24h过期 -- 生成Token并入队 local token = user_id .. '_' .. request_id .. '_' .. redis.call('TIME')[1] redis.call('LPUSH', queue_key, token) return {1, 'queued', token}# consumer/mysql_writer.py import redis import pymysql import logging import time logger = logging.getLogger(__name__) class SeckillConsumer: """秒杀异步消费者：从Redis队列消费到MySQL""" def __init__(self, redis_client, mysql_conn, batch_size: int = 10): self.redis = redis_client self.mysql = mysql_conn self.batch_size = batch_size def consume(self, queue_key: str, stock_table: str): """消费秒杀队列""" while True: tokens = [] # 批量获取Token for _ in range(self.batch_size): token = self.redis.rpop(queue_key) if token: tokens.append(token.decode()) if not tokens: logger.debug("Queue empty, sleeping...") time.sleep(0.1) continue # 批量写入MySQL try: cursor = self.mysql.cursor() for token in tokens: user_id, request_id, _ = token.split('_') # 实际扣减库存+创建订单 cursor.execute(f""" UPDATE {stock_table} SET stock = stock - 1 WHERE sku_id = 12345 AND stock > 0 """) if cursor.rowcount == 0: logger.error(f"MySQL stock deduction failed for {token}") # 补偿：回滚Redis库存 self.redis.incr('seckill:stock:12345') continue self.mysql.commit() logger.info(f"Batch processed: {len(tokens)} orders") except Exception as e: self.mysql.rollback() logger.error(f"Consumer batch failed: {e}") # 重新入队或写入死信队列 for token in tokens: self.redis.lpush(queue_key + ':dlq', token)四、超卖0容忍 vs 少卖可接受：不同业务的库存一致性策略
不同业务对库存一致性的要求是天差地别的。手机秒杀要求0超卖——多卖一台就要赔一台（赔偿用户或重新生产），但少卖几台完全可以接受（库存可以下次活动继续卖）。机票超售则可以容忍一定比例的超卖，因为总有用户退票改签——这个比例通过历史数据模型来优化。金融理财产品则要求精确一致——卖出的份额必须严格等于实际库存，少卖和多卖都是合规问题。
一致性策略的选择直接决定了架构复杂度。0超卖场景使用Redis原子扣减+串行消费到MySQL能够满足要求。容忍少卖的场景甚至不需要Redis——直接MySQL行锁扣减简单可靠。精确一致的金融场景则需要TCC两阶段提交+日终对账的完整保障。
五、总结
秒杀数据库架构的核心思路是"在数据库之前截流"，通过网关限流→Redis原子库存→异步持久化三层解耦，将数据库压力从10万QPS降低到1000QPS。Redis Lua原子扣减是防止超卖的关键实现，幂等性检查是防止重复扣减的安全网。最重要的工程经验是：不要试图让数据库承受秒杀级的并发——即使硬件上可行，成本也是惊人的。将数据库定位为"最终的持久化存储"而非"实时的事务处理引擎"，用缓存和消息队列在中间做缓冲。
