【Day 9】性能战术千万级QPS秒杀系统设计一、题目还原某大型电商平台计划在618大促期间推出限量秒杀活动预计活动开始瞬间将迎来千万级QPS的并发请求洪峰历史最高峰值约1200万QPS而常规业务峰值仅约50万QPS。活动核心需求包括1用户点击立即秒杀后2秒内必须得到成功/失败反馈秒杀成功的用户需在5分钟内完成订单支付2系统必须保证不发生超卖——商品库存数据准确、不得出现负库存3活动期间系统必须持续可用任何单点故障不得导致整体服务中断4普通浏览、商品详情、下单、支付等核心链路必须与秒杀链路相互隔离互不影响5在满足以上要求的前提下尽可能控制IT成本资源按峰值购买会造成巨大浪费。请针对上述需求回答以下问题描述该系统的关键性能质量属性场景完整6元素场景列出为满足性能要求可采用的架构战术并说明在秒杀系统中的具体落地方式秒杀链路中应如何设计多级缓存与限流策略比较漏桶算法与令牌桶算法的适用性分析秒杀系统采用微服务消息队列事件驱动架构风格的理由。二、考点分析本题属于质量属性与战术分析答题模板二的经典变形核心考察性能Performance质量属性交叉考察性能战术三大类资源需求/资源管理/资源仲裁的识别与落地限流算法漏桶 vs 令牌桶的机制对比与选型多级缓存架构CDN→本地→分布式→DB及缓存穿透/击穿/雪崩防护异步削峰消息队列与架构风格选择微服务事件驱动。答题框架模板二范式1. 关键质量属性性能辅以可用性 2. 质量属性场景刺激源→刺激→环境→制品→响应→度量6元素 3. 采用战术战术①资源需求类…战术②资源管理类…战术③资源仲裁类… 4. 架构风格选型微服务事件驱动理由逐条对应题干需求三、标准答案采分点格式问题1性能质量属性场景6元素① 刺激源Source秒杀用户海量并发消费者② 刺激Stimulus活动开始瞬间同时发起立即秒杀请求峰值约1200万QPS③ 环境Environment大促高峰、系统满负荷运行状态④ 制品Artifact秒杀网关、下单服务、库存服务⑤ 响应Response系统限流放行、校验库存并返回秒杀结果成功/失败⑥ 响应度量Measure秒杀请求2秒内返回结果秒杀接口吞吐量≥1000万QPS库存扣减准确率100%零超卖加分可补一条可用性场景——刺激源硬件故障刺激库存Redis主节点宕机响应自动切换从节点度量切换30s、零数据丢失问题2性能战术列表分类具体落地一资源需求战术减少对资源的需求减少计算开销多级缓存。CDN缓存秒杀静态页面Nginx本地缓存页面片段Redis分布式缓存商品详情与库存预扣使绝大部分请求在缓存层直接返回不穿透数据库管理事件率限流。网关层对秒杀接口做令牌桶限流超过阈值的请求直接返回已抢完防止洪峰压垮后端控制采样频率秒杀按钮置灰、前端随机延迟/答题验证人为降低瞬时请求密度。二资源管理战术更高效利用资源引入并发异步化处理。秒杀请求先写入消息队列Kafka/RocketMQ削峰填谷订单系统异步消费下单与支付解耦IO密集操作异步化维护多个副本负载均衡。LVS/Nginx集群 Redis集群分片 数据库读写分离/分库分表多副本分担压力增加可用资源水平扩展。秒杀服务无状态化按流量弹性伸缩容器编排自动扩容活动前预扩容。三资源仲裁战术调度资源访问顺序调度策略库存扣减采用Redis Lua脚本原子操作内存态扣减异步落库先到先得消息队列按优先级消费抢占机制秒杀成功用户的高优支付请求优先处理优先级队列。问题3多级缓存设计与限流算法比较多级缓存架构由外向内CDN静态页面→ Nginx本地缓存页面片段→ Redis集群商品详情、库存预扣、用户状态→ MySQL最终数据。设计目标99%以上请求止步于Redis之前数据库只承受最终落库与对账流量。缓存三大问题及对策必答缓存穿透查询不存在的数据绕过缓存直击DB→ 布隆过滤器 空值缓存缓存击穿热点key过期瞬间大量请求打到DB→ 互斥锁仅放一个线程回源 热点key永不过期/逻辑过期缓存雪崩大量key同时失效或Redis宕机→ key过期时间加随机抖动 Redis集群高可用主从哨兵/Cluster 熔断降级。限流算法对比漏桶Leaky Bucket请求以固定速率流出超出桶容量的请求被丢弃或排队。优点输出速率绝对恒定下游负载稳定缺点无法应对突发流量瞬时尖峰被直接拒绝造成有量无质。令牌桶Token Bucket以固定速率向桶中放令牌请求须获取令牌才能通过桶满则丢弃令牌。优点允许一定程度的突发桶容量即突发上限既能平滑流量又能吸收短时尖峰更契合秒杀瞬时洪峰总量有限的特征。选型结论网关层用令牌桶应对秒杀瞬时洪峰若下游组件如数据库连接池对速率绝对敏感内层再叠加漏桶或计数器限流单机限流如Guava RateLimiter与分布式限流RedisLua、Sentinel双层部署。问题4架构风格选择理由选择微服务架构 事件驱动消息队列混合风格。理由① 微服务按业务能力拆分商品、库存、订单、支付、用户秒杀链路独立成服务满足需求4链路隔离——秒杀流量不拖垮常规业务② 服务独立部署、独立扩容满足需求5成本可控——只为秒杀服务弹性扩容而非整体扩容③ 事件驱动消息队列实现异步削峰填谷满足需求12秒内反馈——请求先入队即返回排队中异步处理结果再通知把峰值压力转化为队列积压平滑写入端负载④ 库存服务无状态化多副本配合Redis原子扣减满足需求2零超卖与需求3高可用。不适用风格可答管道-过滤器数据流驱动适合批量处理不适合高交互、强状态库存一致性的在线交易黑板/解释器控制逻辑分散、运行开销大无法满足千万级QPS单体层次架构无法独立扩容秒杀模块全局耦合不满足隔离与弹性要求。四、评分要点必答点采分核心① 完整6元素性能场景——源/激/环/制/应/度量缺一不可度量必须量化QPS、毫秒、准确率每缺一个元素扣相应分值② 战术分类正确——必须按资源需求/资源管理/资源仲裁三类作答并各举至少1例只写用缓存、用限流而不分类不给分类分③ 限流算法机制描述准确——漏桶恒定速率输出令牌桶允许突发选型结论合理④ 缓存分层顺序正确——CDN→本地→分布式→DB且答出穿透/击穿/雪崩三对策⑤ 消息队列削峰填谷的定位——异步化、解耦、缓冲写清楚入队即返回、异步处理。加分项点出先扣Redis库存、异步落库、最终一致对账的双写一致性方案布隆过滤器、互斥锁、过期时间随机抖动等专业术语准确体现权衡意识性能 vs 成本 vs 一致性如放弃强一致换取可用性与性能BASE有容量规划数字如单机5万QPS×200台≈1000万QPS体现工程思维。常见失分点场景元素笼统描述“用户/系统”而不量化限流只写限流二字不区分算法机制缓存只说Redis不交代层级位置战术不分类名词堆砌。五、扩展知识点性能 vs 可伸缩性易混淆对照表性能关注响应时间与吞吐量可伸缩性关注处理能力随资源增长的比例。秒杀既要性能低延迟又要可伸缩性弹性扩容但性能好≠可伸缩性好——单机优化到极致不如加机器有效。服务降级 vs 熔断易混淆对照表降级是主动放弃非核心功能秒杀时关闭评论、推荐等非核心接口熔断是被动停止对失败服务的调用库存服务异常时熔断秒杀入口。秒杀系统两者并用务必写清区别。Cache性能公式必背公式速查卡平均访问时间 T H×T_cache (1-H)×T_mem。设Redis命中率H0.95Redis访问1ms、DB访问100ms则T0.95×10.05×1005.95ms相比直连DB提升约17倍——多级缓存的量化价值计算题直接套用。Amdahl定律S1/((1-f)f/k)说明热点链路单点优化收益有限最终要靠水平扩展——秒杀场景可引用论证必须并行扩容而非死磕单机。CAP/BASE秒杀库存扣减是典型AP权衡——放弃强一致换取高可用与高性能以最终一致性异步落库对账兜底。可用性战术联动Day 8双活数据中心秒杀高可用依赖故障检测心跳故障恢复主从/双活故障预防消除单点与今日性能战术合并即为性能可用性双属性标准答卷。架构风格联动Day 4事件驱动事件驱动发布-订阅异步解耦秒杀的消息队列即事件驱动风格实例对比Day 1数据流风格——数据流是数据在管道中流动事件驱动是事件触发响应。六、今日金句性能战术三件套资源需求减消耗缓存限流、资源管理扩供给并发副本弹性、资源仲裁定分配调度抢占秒杀架构的真谛——缓存挡掉读、队列削掉峰、限流护住底、异步保一致。
)
