活动系统最怕的，不一定是全站流量都高。
更麻烦的是一个商品突然爆了。
首页总 QPS 看起来还能接受，但某个商品详情页、某条库存记录、某个活动资格接口被集中访问。平均值很好看，局部资源已经被打穿。
热点和突发流量真正难的地方，是不均匀。
热点流量有时候来得很突然。
一个商品被推荐了，一个活动被转发了，一个接口被 App 首页反复刷新。平时看起来平均的流量，突然集中到一个 Key、一个页面、一个接口上。
监控上看，整体 QPS 可能还没到系统上限，但某个 Redis 分片、某台应用机器、某个数据库分区已经先扛不住了。
所以热点最麻烦的地方，不是流量大，而是它不均匀。平均值会骗人。
只看平均 QPS，很容易错过那个真正冒烟的商品、用户、设备或 Key。
一、秒杀不是普通下单的放大版
秒杀和抢购最容易制造突发流量。
它看起来只是下单，但实际会同时考验入口限流、库存扣减、排队、异步处理、防重复提交、防刷、支付超时和失败补偿。
如果直接把所有请求放进正常下单链路，数据库和库存系统大概率会被打爆。
更稳的方式通常是：
前端限流
-> 网关限流
-> 资格校验
-> 库存预扣或令牌
-> MQ 排队
-> 异步创建订单秒杀的关键不是让所有请求都进入系统，而是尽早过滤掉不可能成功的请求。
二、热点商品和热点库存要拆开设计
热点商品详情一般是读多写少，可以用缓存、本地缓存、多副本缓存来承接。
热点库存不同。库存会变化，而且涉及超卖问题，不能只靠普通缓存解决。
常见做法包括库存预热、库存分桶、Redis 原子扣减、数据库最终校验、订单超时释放。
我会把商品信息和库存扣减拆开设计：商品信息偏读优化，库存链路重点保证正确性和幂等。
把两者混在一起，很容易既拖慢读，又搞乱写。
三、热点不一定来自商品
热点可能来自很多维度。
一个大客户、一个热门主播、一个异常账号、一台高频上报设备，都可能成为热点。
热点用户的问题通常是单用户维度请求过高，导致账户、订单、余额、权限等数据被频繁读写。热点设备的问题常见于物联网、制造业、监控系统，高频状态上报可能把某个设备维度的数据写爆。
这类问题要靠维度识别。
监控里不能只看全局 QPS，还要能看到 Top 用户、Top 商品、Top 设备、Top Key。
看不见热点，就谈不上治理。
四、突发报表也是一种重流量
还有一种热点来自后台。
比如运营临时查一个大范围报表，财务导出一年数据，管理后台做复杂筛选。请求量不一定高，但单次查询很重。
这类流量如果直接打在线库，可能影响正常交易。
更好的方式是异步导出、报表库、预聚合、限制查询范围、限制导出频率。很重的查询可以让用户提交任务，后台生成文件后再下载。
后台系统不是低风险系统。它只是访问人数少，但单次操作可能很重。
五、高峰期要削峰，也要分级
高峰期流量削峰，不只是加 MQ。
入口要限流，核心链路要优先，非核心功能要降级，后台任务要错峰，低优先级数据可以延迟处理。
比如活动开始前，提前预热缓存和库存；活动中，关闭非核心统计；活动后，再慢慢补齐报表和分析数据。
高峰期真正要保护的是核心业务闭环。只要下单、支付、库存这些链路稳住，评论数晚一点、排行榜慢一点，用户通常可以接受。
六、可以带走的判断清单
- 不只看全局 QPS，要看 Top Key、Top 用户、Top 商品。
- 商品详情和库存扣减要分开设计。
- 秒杀要尽早过滤不可能成功的请求。
- 后台报表也可能拖垮在线库。
- 高峰期要区分核心链路和非核心链路。
- 局部热点要隔离，不要让它拖垮全局。
高并发架构不是只看平均值。很多事故，都是平均值很好看，局部已经烧起来了。
本系列：
暂无评论