扛住 10000 QPS 秒杀的高并发系统设计：五层缓冲与限流熔断落地指南-编程实验室

扛住 10000 QPS 秒杀的高并发系统设计：五层缓冲与限流熔断落地指南

【免费下载链接】geektime-books:books: 极客时间电子书项目地址: https://gitcode.com/GitHub_Trending/ge/geektime-books

秒杀活动开闸的第一秒，1 万个用户同时点下"抢购"按钮。如果请求一个都不拦，数据库连接数会瞬间冲上万，MySQL 当场趴下。这篇文章用极客时间《88-高并发系统设计40问》里的真实例子，把高并发系统设计的"分层削流量"思路拆开讲：流量要分五层消化，每一层拦什么、怎么配、配错会踩什么坑。

🚀 场景走读：一次秒杀请求的完整旅程

先把全景建立起来。用户从点按钮到看到"抢购中"的提示，请求依次穿过五道关卡：

CDN 层：商品页里的图片、视频这类能被静态化的数据，直接命中 CDN 节点，根本到不了服务器。
缓存层：用户查的是同一批热点商品，书里的做法是让 Nginx 直接访问分布式缓存节点，把请求挡在 Tomcat 之前。
网关限流层：同一用户、同一 IP、同一设备的短时间重复请求，在这里直接丢弃。
队列层：真正要下单的写请求全部塞进消息队列排队，响应立刻返回"结果正在计算中"。
数据库层：落到 MySQL 的并发量，等于队列处理程序的线程数，是一个你说了算的固定值。

五层里，前四层都在做同一件事：让尽可能少的请求，以尽可能平的速率，摸到数据库。

难点拆解：四层缓冲各自的配置要点

限流算法怎么选：窗口、漏桶、令牌桶的取舍

现象：限流明明开了，大促时照样被打穿；或者限流一开，正常请求的延迟肉眼可见地变高。

成因：按书中的说法，问题多半出在算法选型和实现位置。固定窗口计数（每分钟记一次数，超了就拒）实现最简单，但挡不住短时间的集中流量；而把限流放在单机上，多机部署时每台机器各限各的，总流量照样超标。

解法：四种主流算法的对比如下：

算法	核心思路	适用场景
固定窗口计数	每个时间窗口记一次数，超阈值拒绝，下个窗口清零	粗略控制，实现成本最低
滑动窗口计数	把窗口切成多个小格分别计数，平滑边界峰值	对精度要求较高的入口
漏桶算法	请求先堆进桶里，出口按固定速率匀速放出	必须把流量"整形"成平流的链路
令牌桶算法	像售票处的取票机，按固定速率放票，桶里可囤票应对小高峰	API 网关、接口限流（实际项目中最常用）

书里更倾向令牌桶：漏桶把突发流量缓存在桶里，会拉长用户等待时间，和互联网业务低延迟的诉求相悖；令牌桶则允许桶里暂存一批令牌，突来一波小高峰能直接发出去。另一个容易忽略的点：分布式环境下令牌数量通常存在 Redis 里，每次只取一个令牌，每个请求就多跑一趟 Redis。折中办法是一次取一批令牌，本地用完再去取，把 Redis 往返次数压下去。

为什么一个慢服务能拖垮整个系统：熔断与降级

现象：大促复盘时发现，挂掉的不是数据库，而是整条调用链——明明只有推荐服务响应变慢，下单接口却跟着超时了。

成因：分布式系统最怕的从来不是某个服务宕机，而是它响应变慢。书里给了一个很典型的雪崩链路：A 调 B，B 同时调核心服务 D 和非核心服务 C。流量上涨时团队只给 A、B、D 扩容，C 没跟上，处理变慢。B 调 C 的请求全部阻塞住等结果，线程被占满，B 的线程池队列积压，反过来把 A 拖死。一个非核心服务的慢响应，放大了整条链路。

解法：思路只有一个——检测到依赖服务响应异常时，快速失败，把占住的资源立刻还回来。具体手段对比：

手段	核心思路	适用场景
熔断	失败次数超阈值就"断开电路"，后续请求直接返回错误；定时器周期性探测，探活成功才恢复	依赖服务、Redis 节点出现慢响应或持续失败
开关降级	代码里预埋开关（值放配置中心），开关一拨就跳过远程调用、返回兜底数据	非核心功能整体放弃，保主流程
限流降级	入口拒绝超出承载能力的请求	峰值流量超出预估，保核心接口

熔断的实现可以理解为每个被调服务维护一个三态状态机：关闭（正常调用）→ 失败数攒够阈值切到打开（拒绝请求）→ 计时器到期切到半开（放少量试探请求）→ 累计成功则回到关闭，再失败则重新打开。这套逻辑不只用于微服务，团队给 Redis 客户端也封装了一份：Open 状态下用定时器 ping 节点探活，熔断期间操作直接返回空值。

消息队列削峰：处理程序开几个才够

现象：库存只剩 1000 件，消息队列里的下单请求却堆了几万条，用户等了半分钟还是看不到结果。

成因：队列处理程序开太少，消化速度跟不上。书里给了一笔很实用的账：单件商品下单处理耗时 500ms，1 个处理程序清完 1000 件要 500 秒；开到 10 个，总耗时压到 50 秒，同时打到数据库的并发也只剩 10，压力完全可控。

解法：先做容量评估（商品数 × 单条处理耗时 ÷ 可接受的等待时间），再定处理程序数量。

处理程序数量	1000 件全部处理的耗时	数据库同时承压的并发
1 个	500 秒	1
8 个	400 秒	8
10 个	50 秒	10

注意两个边界：库存扣完之前，队列里堆积的多余请求可以直接丢弃，不必处理；但"让用户等结果"只适用于秒级到几十秒的量级，等太久用户会怀疑活动有猫腻。

哪些步骤能扔进异步：砍掉流程里的"陪跑"耗时

现象：压测显示单次下单要 500ms，其中生成订单和扣库存才是主角，剩下的时间花在了不重要的事上。

成因：下单成功后的发优惠券、加积分各占 50ms，却和主流程串行执行，等于每次下单都多陪跑 100ms。

解法：把这类次要逻辑挪到另一个队列处理程序里异步执行。整条链路从 500ms 缩到 400ms，性能提升 20%，前面算的 10 个处理程序直接省出 2 个。判断标准就一条：这一步慢一点，用户当下感不感知？感知不到，就异步。

踩坑与排障：三个"哪里出了问题"的真实案例

坑一：限流阈值没设错，但限流就是没生效

现象：压测报告显示每秒进来 20 个请求，超过了"每秒 10 个"的限流阈值，却被放行了。根因：用的是固定窗口。前 10 个请求集中在第 1 秒的最后 10 毫秒，后 10 个出现在第 2 秒的前 10 毫秒，窗口一换各自计数都没超，20 毫秒内的瞬时冲击就这么溜过去了。修复：换用滑动窗口或令牌桶这类能感知窗口边界的算法；阈值别拍脑袋，放在配置中心里，靠定期压测出来的实际承载能力来定，方便动态调整。

坑二：扩容做了，雪崩照样发生

现象：大促当天流量翻倍，核心链路跟着超时，事后发现源头只是反垃圾服务响应变慢。根因：扩容只覆盖了核心服务，非核心服务没跟上；调用方对慢依赖没有快速失败机制，线程被慢请求一路占住。修复：给所有外部依赖（包括 Redis 这类组件）加熔断器，响应时间异常就快速返回失败；非核心功能预留降级开关，必要时从配置中心一键关闭，不重启服务。

坑三：单机限流上了分布式，性能反而变差

现象：多机部署后把令牌桶改到 Redis 上，每个请求多一次 Redis 往返，网关整体延迟涨了数毫秒。根因：进程内的令牌变量在机器之间不共享，改造时图简单做成了"每请求取一个令牌"。修复：改为每次从 Redis 批量领取一批令牌，在本地消费，取令牌的频率降了一个数量级，Redis 压力和请求延迟同时回落。