一次没顶住的流量 去年大促，预估峰值 8000 QPS，实际来了 1.4 万，订单服务被打挂 12 分钟。复盘发现：我们的容量评估靠的是"去年×2"的拍脑袋，没有真实压测支撑，对系统的真实拐点一无所知。那天凌晨告警炸了，扩容来不及，限流没配，全靠手动重启扛，资损不小。这次我把容量评估正经做了一遍，把
面试官问：100 万人抢 1000 件商品怎么设计 前阵子做架构分享，被同事用一道经典题考住："100 万并发抢 1000 件商品，怎么保证不超卖、系统还不挂？"这题看着老，但真要落地，每一层都有坑。我把我们实际做过的秒杀系统的设计要点拆开讲——不是教科书，是踩过坑的版本。 要点一：库存扣减，必须原
GC 选型的争论：Shenandoah 还是 ZGC 我们一个时延敏感的交易网关，之前用 G1，业务高峰 P99 偶尔冲到 400 ms，排查发现是 G1 的 Mixed GC 有 100~200 ms 的停顿。组里就"换哪个低延迟 GC"吵开了：有人挺 Shenandoah，有人挺 ZGC。我干脆
目标：大促前把商品详情接口压到 8000 QPS 9 月 20 号拿到大促的容量需求：商品详情接口要扛 8000 QPS，P99 控制在 300 ms 以内。第一次压测跑下来只有 2000 QPS，P99 1.2 秒，差了 4 倍。 前后两周五轮优化，最后压到 8200 QPS、P99 178 ms
高并发系统限流方案：Sentinel 实战 在微服务架构中，流量控制是保证系统稳定性的关键技术。Sentinel 是阿里巴巴开源的流量控制框架，提供了丰富的限流功能。 Sentinel 核心功能 流量控制 基于 QPS 的直接限流 基于并发数的限流 基于匀速排队的限流 熔断降级 慢调用比例熔断 异常
