高并发实战与优化：秒杀系统设计

可视化演示

展示CDN-限流-缓存-库存-异步多级削峰架构、Redis原子减库存与防超卖，以及消息队列异步化处理，滑杆调节并发流量。

高并发挑战：洪峰为什么可怕

春运第一天的清晨，城市最大的剧场开门放票，一万张演出票瞬间迎来 80 万人的抢购洪流。如果让所有人都冲到四个售票窗口前排队，会发生什么？窗口系统被超过负荷的等待队列拖垮，页面响应从 200 毫秒劣化成 20 秒；更可怕的是，因为多个请求同时操作同一条库存记录，最终票会被卖出 10500 张——超卖的 500 张让剧场陷入纠纷。秒杀的困难从来不是“人多”，而是“这么多人对同一条数据的读写无法同步”。

技术上的本质困难有三个。第一，瞬时流量不匹配：平时系统 QPS 可能只有 500，秒杀瞬间冲到 50 万，1000 倍的差异让任何常规接口都瞬间成为瓶颈。第二，热点集中：所有请求都盯着同一个商品 ID，所有读写都落在同一行库存记录上，数据库行锁变成全局瓶颈。第三，读改写竞争：多个请求同时读到“库存为 1”，各自判断可以购买，随后各自扣减，最终写回负数。衡量系统压力时，我们最常使用 QPS 指标。

其中 T_{rt} 是平均响应时间（毫秒），C 是同时处理的并发请求数。

所以，秒杀设计的第一步不是急着写代码，而是先承认：既然无法靠单机硬扛洪峰，就必须像剧场一样，在入口、大厅、窗口前分别设置闸机、显示屏和取号机，让每一层流量都被消化一部分。后面每一节，都是这套分流工程的一个环节。

多级缓存架构：层层分流查询压力

剧场很有经验：开票前先在广场大屏滚动显示“余票 850 张”，候车厅的电子屏每 3 秒同步一次，检票口的小屏显示“本口已售 213 张”。大多数观众看到大屏就知道“还有票”，根本不会都挤到窗口前再问一句“还有票吗”。这就是多级缓存——用越来越靠近用户的“信息展示”，替后端数据库挡住 99% 的重复查询。

多级缓存的工程形态自外向内依次是：CDN 与静态页面（把秒杀页提前渲染为静态 HTML，秒杀开始后直接刷新的次数极少）、浏览器与本地缓存（按钮置灰、倒计时防止重复点击）、应用本地缓存（如 Caffeine，存热点商品信息）、Redis 集群（承载绝大多数读请求），最后一层才是数据库。越靠外的层访问速度越快、能存的数据越少、数据越旧；越靠内的层越接近真实票源。核心难点是缓存击穿：某个热点 key 在过期的一瞬，海量请求同时发现“缓存没了”，于是统统打到数据库。解决思路有三种：互斥锁（只让一个请求去数据库回源，其余等待）、逻辑过期（热点数据不设物理过期时间，后台异步刷新）、过期时间加随机值（防止同时失效演变成雪崩）。

这就像剧场的三层显示屏：越靠前的屏越大、刷新越慢、数据越旧；真正精准的数字，只有售票窗口里的那个小屏才有。设计者是用“空间换时间”——用稍旧的数据，换掉了后端数据库上 95% 以上的查询压力。

入口限流方案：闸机控制流量

剧场检票口前有一道旋转闸机，保安设定好“每秒钟最多放行 30 人”。来多少人都不怕，闸机的转速始终不变；就算有人硬挤，也会被隔在门外。这种“匀速放行、超出就等”的机制叫限流。有一类更聪明的闸机，里面藏着一个“令牌盒子”：盒子每秒匀速掉出一枚令牌，进闸的人必须先抢到一枚令牌；盒子最多存满一盒，多余的令牌自动丢弃。令牌多的时候可以瞬间放进一批人，但长期速率被盒子牢牢控制。这就是令牌桶算法，它允许突发流量，非常适合秒杀初期“流量脉冲式上涨”的节奏。

令牌桶算法的核心参数是 r（令牌补充速率）和 N_capacity（桶容量，即最大突发量）。每个请求必须取走一枚令牌，桶空则拒绝或排队。相比固定窗口，令牌桶不会在窗口切换瞬间出现“双倍放行”的问题；相比漏桶，它又允许短时间冲进一小波流量。工程上可以用 Redis 加 Lua 脚本实现分布式令牌桶，让所有前端节点共享同一个限流状态。

闸机把汹涌的人潮梳成细流，剧场才不会被瞬间挤爆。限流从来不是为了拒绝用户，而是把“所有请求同时打到系统”这个不可能的任务，变成“系统可承受范围内的有序请求”。

Redis原子扣减：机械计数器防超卖

剧场售票窗口里，售票员用的是老式机械计数器：每卖一张票必须按一下按钮，数字才减一；就算两个售票员同时伸手去按，内部的棘轮也只允许一方生效，绝不会出现“两个人都以为卖到了最后一张票”的情况。这就是原子性。秒杀里的库存扣减，也必须保证这种“同时只允许一个成功”的原子效果，否则就会超卖。

最简单也最容易踩坑的做法是：先 GET 库存，再 DECR 库存。但这两步之间，另一个请求可能插进来，导致两个请求都读到库存等于 1，各自减一，最终变成 -1。Redis 的 DECR 命令本身是原子的，但“先判断库存 >0 再减一”这个组合并不是原子的。正确方案是使用 Lua 脚本，把“检查 >0”与“减一”合并到 Redis 服务器端的一段脚本里执行，Redis 会保证整个脚本执行期间不会有其他命令插队。无论并发请求有多少个，库存只会被减到 0，绝不为负。

计数器的棘轮结构（原子性）保证了不会超卖。但要记得，Redis 扣减只是“计数层面”的正确，后续若订单没生成或用户没付款，还需要把库存加回去，这就与订单流程和消息队列的配合有关了。

消息队列削峰：取号机制平滑洪峰

剧场发现，如果 1000 个观众同时堵在四个窗口前排队，队伍会一直排到马路上。于是改成“取号制”：观众先在取号机上拿到一个号，然后去候场区休息，听到叫号再去窗口。取号机每秒能发 2000 个号（快），窗口每秒只能办理 30 个（慢），但人群不再拥挤，因为中间多了一个缓冲区。这就是消息队列的削峰填谷。

秒杀下单的常规流程是：请求 → 校验 → 扣库存 → 写订单 → 返回结果。但写订单涉及数据库落盘，速度慢且有锁冲突。削峰方案把流程拆成两段：请求入口只做校验、限流，然后把用户 ID 和商品 ID 写入消息队列，立即返回“下单排队中”；后端的消费者从队列里慢慢取消息，真正执行 Redis 扣减和数据库订单写入。通过调节消费者的并发数和消费速率，系统可以在几秒甚至几分钟内慢慢消化掉流量洪峰。用排队论的术语，系统负载强度为：

其中 λ 为平均到达率（每秒新到多少请求），μ 为平均服务率（每秒能处理多少请求）。

取号机让观众不再堵在窗口前，消息队列让数据库不再直面洪峰。它以“缓一缓”的方式把尖峰抹平，这正是秒杀系统承载百万流量的关键一跃。

订单流程设计：锁座出票状态机

买票不是窗口大妈喊一声“卖给你了”就结束。真实流程是：你先“锁座”——预占一个座位，15 分钟内付款，付完才正式出票；超时不付，座位自动释放给下一个人。每一步都有明确状态，绝不混乱。这就是订单状态机。秒杀订单如果“抢到即落库”，数据库会在瞬间被几十万条订单写入打垮，所以工程上采用“先 Redis 后 MySQL”的两段式设计。

用户抢到资格后，先在 Redis 中保存一条“待支付”的订单草稿，同时完成库存扣减；用户支付时，再把订单异步落库到 MySQL 成为正式订单。如果用户超时未支付，延迟队列会触发“库存回滚”，把扣掉的库存加回去，并把订单状态改为已取消。同时必须设计幂等：同一订单的支付回调可能到达两次，必须依靠订单号加状态字段保证只处理一次，否则会出现重复扣款或重复发货。

剧场用“锁座—付款—出票”管理座位，系统用状态机管理订单。前端一次点击买票，后端不是一次简单的调用，而是一条清晰的状态流转链，每一步出错都有对应的回退方案。

防刷防黄牛：安保组合拳

剧场门口还有一队保安：先查身份证（风控），再验一下验证码（人机识别），然后告诉你“每人限购 3 张”（用户限购），最后如果发现同一批身份证号反复出现，就会触发警报（黑产识别）。这一套组合拳把黄牛挡在门外，保证普通观众买得到票。

秒杀最常见的刷单方式有三类：脚本机器人毫秒级重复点击、多账号批量注册、代理 IP 池不断更换地址。对应的防护手段也分四层：第一层接口风控，对用户 ID、设备 ID、IP 做频率统计与黑白名单；第二层人机校验，滑块/图形验证码能够显著抬高脚本的破解成本；第三层用户维度限购，同一用户最多买 N 件，用 Redis 计数器实现；第四层数据风控，对异常聚集模式（同一设备大量账号、同一 IP 大量用户）做离线聚类识别。需要特别注意的是，风控必须放在限流和库存扣减之前，否则黄牛会先消耗掉宝贵的放行额度。

秒杀在某种程度上是“人与脚本的赛跑”。剧院的保安越严格，普通观众买到票的概率越高；系统的风控越细致，真用户被机器人挤掉的概率就越低。防刷不是把门锁死，而是把开锁成本提高到机器人不愿意付出的水平。

压测与监控：演练与调度大屏

春节前，剧场要做一次应急演练：模拟 5 万人同时涌向大门，测试闸机放行速度、候车厅容纳量、售票窗口的处理极限。演练会发现“东门太窄”“提示牌不清晰”等问题，然后逐一整改。上线运营后还有调度大屏，实时显示各区域的人流拥堵指数。秒杀系统的压测与监控，就是这个思路。

全链路压测是在灰度环境或线上用回放流量模拟真实秒杀流量，观测各环节瓶颈：数据库连接数、Redis 内存、网络带宽、消息队列积压量。核心指标包括 QPS、RT 的 P99 延迟、错误率、CPU/内存/磁盘水位、MQ 积压数。告警监控要设置合理阈值，比如 MQ 积压超过 1 万条、Redis 命中率低于 90%、错误率超过 1%，通过监控大盘与电话告警及时发现问题，并配合自动扩容、动态限流开关进行治理。线上出现超卖或卡顿时，依靠全链路 Trace（如 SkyWalking）定位耗时到底在哪个环节，再针对性优化。

剧场的演练是为了避免“庆典变事故”。秒杀系统的压测监控，就是在真正开票前把所有隐患暴露一遍，把“祈祷别出问题”变成“我们知道可能会出什么问题，并且预案已经准备就绪”。

AI 应用场景

Python 演示

# 模拟秒杀系统：1000个用户抢10件商品# 链路：令牌桶限流 -> 消息队列削峰 -> 原子扣减库存import threadingimport timefrom queue import Queue class TokenBucket:    def __init__(self, rate, capacity):        self.rate = rate            # 每秒补充令牌数        self.capacity = capacity    # 桶容量        self.tokens = capacity        self._lock = threading.Lock()        self._last = time.time()     def take(self):        with self._lock:            now = time.time()            added = (now - self._last) * self.rate            self.tokens = min(self.capacity, self.tokens + added)            self._last = now            if self.tokens >= 1:                self.tokens -= 1                return True            return False class AtomicStock:    def __init__(self, initial):        self.stock = initial        self._lock = threading.Lock()     def try_decr(self):        with self._lock:            # 模拟 Redis Lua 脚本的原子性            if self.stock > 0:                self.stock -= 1                return True            return False class OrderWorker(threading.Thread):    def __init__(self, q, stock_keeper):        super().__init__(daemon=True)        self.q = q        self.stock_keeper = stock_keeper     def run(self):        while True:            user = self.q.get()            if self.stock_keeper.try_decr():                time.sleep(0.01)    # 模拟写订单耗时                print(f'用户 {user} 抢购成功')            else:                print(f'用户 {user} 来晚了，已售罄')            self.q.task_done() def main():    stock_keeper = AtomicStock(10)  # 库存 10 件    bucket = TokenBucket(rate=5, capacity=10)  # 每秒 5 个令牌    order_q = Queue()               # 消息队列    OrderWorker(order_q, stock_keeper).start()     passed = 0    for uid in range(1, 1001):      # 1000 个用户同时抢        if bucket.take():           # 入口限流            order_q.put(uid)        # 先入队，异步扣减            passed += 1        else:            print(f'用户 {uid} 被限流拦截')     order_q.join()                  # 等待队列处理完成    print(f'放行 {passed} 个请求，剩余库存 {stock_keeper.stock}') if __name__ == '__main__':    main()

1. self.tokens = min(self.capacity, self.tokens + added)按时间补充令牌，但总量不超过桶上限。
2. if self.tokens >= 1:有令牌才放行，这是限流的核心判断。
3. if self.stock > 0:库存大于零才允许扣减，对应 Redis Lua 脚本里的关键判断。
4. order_q.put(uid)请求先进入消息队列而不是直接写库，实现削峰。
5. OrderWorker(order_q, stock_keeper).start()启动消费者线程，异步处理订单。
6. order_q.join()主线程等待所有排队消息处理完毕。

常见误区

面试题