四年，十次告警，数十个技术决策：一个海外电商平台的高并发治理实录
半夜两点被电话叫醒这件事，做了四年海外电商平台后，我从一开始的心惊肉跳，到后来的波澜不惊，中间隔着的不是心态，是实实在在的十次线上高并发告警，以及围绕每一次告警做出的那几十个技术决策。
这个平台服务欧美和东南亚用户，业务形态是典型的跨境电商：大促秒杀、限时折扣、直播带货，一个不少。流量特征是瞬间尖峰极高、区域性明显、链路长且依赖多。做高并发治理，说白了就是跟流量较劲，但更准确地说是跟流量的不确定性较劲。这篇文章我把这四年里踩过的坑、做出的关键决策、沉淀下来的方案一次性讲透，希望能给正在做或准备做高并发系统的朋友一些参考。
1. 项目背景与四年治理全景：从“救火队员”到“架构体检”
1.1 这是一个什么样的系统，为什么会反复被流量打穿
平台的核心链路是用户端App/Web → API网关 → 商品服务 → 库存服务 → 订单服务 → 支付服务，下游还挂着会员、营销、搜索、推荐等一系列微服务。中间件层面用了Redis做缓存、RocketMQ做异步消息、MySQL做持久化存储，服务注册与配置中心是Nacos，微服务框架是Spring Cloud Alibaba。整个集群部署在Kubernetes上，节点规模高峰期接近两百个Pod。
这套架构在平时看起来很稳，能把日均百万级请求处理得游刃有余。但电商业务有个特点——它的流量不是匀速的，而是脉冲式的。一次大促的瞬时流量峰值可能是平时的五十倍以上，一次运营活动上线可能让某个接口的QPS在几十秒内从几百冲到几万。这种流量模型下，静态的容量规划基本失效，系统随时可能被流量打穿，而且打穿的位置每次都不一样。
四年里我们统计到的P0/P1级别告警一共发生了十次，其中流量突刺导致网关过载三次，缓存击穿把数据库打挂两次，热点Key问题造成集群雪崩一次，下游依赖慢导致线程池耗尽两次，数据一致性问题引起资损风险一次，还有一次是新版本上线时因为一个配置项错误引发的大规模报错。
1.2 十次告警背后的共性规律：高并发从来不是“单点问题”
复盘这十次告警，我发现一个非常核心的规律：高并发治理从来不是某一个环节的事情，而是一条链路上所有环节的共同责任。流量打到网关上，网关拦截不掉，下游的每一个服务都要承受压力；缓存如果没挡住，数据库就会被击穿；数据库如果慢了，所有依赖它的服务线程池都会跟着阻塞。任何一个环节的短板，都会成为整个系统的瓶颈。
真正的高并发治理，不是把某个中间件的参数调大，而是建一整套从流量入口到数据存储的防御体系。这套体系要能在流量到来之前提前预估容量，在流量到来时限制和疏导流量，在局部出现问题时快速隔离和降级，在故障发生后能快速定位和恢复。我用四年的时间才把这一整套逻辑跑通，下面就从系统的三个主要层面来拆解具体怎么做。
2. 流量模型与容量评估：在告警发生前，先用数据预测风险
2.1 线上流量模型的建立与压测体系的搭建
第一次大促前，我们完全依赖经验判断容量，结果就是活动刚开始十分钟网关就扛不住了。那次之后，我做的第一个决策就是建立线上流量模型。具体做法是从网关日志和APM监控里捞取过去三个月的历史流量数据，按接口维度统计QPS均值、TP999耗时、调用链深度、下游依赖数，再结合业务日历把大促因子算进去，形成一个容量预估模型。
这个模型的基本公式是：预估峰值QPS = 历史峰值QPS × 业务增长系数 × 活动因子 × 区域时区系数。比如去年某一次大促，日常峰值QPS大概是两万，业务增长系数是1.3，大促活动因子是3.5，那么预估峰值就是9.1万。有了这个数字，就可以倒推需要多少Pod、多少连接池、多少缓存内存。这个预估不一定精准，但至少不会再出现拍脑袋式的容量规划。
配合容量预估，我们搭建了基于JMeter和Locust的全链路压测体系。压测环境不是独立搭建的测试环境，而是直接复用生产环境的影子流量方案——通过网关把压测流量打到一个专门的压测标记上，后端服务识别到这个标记后走独立的逻辑分支，数据写入影子表。这样压出来的数据才是最接近真实线上情况的。
2.2 容量评估的三个关键参数：QPS、TP999和资源饱和度
有了压测工具还不够，关键是知道要盯哪些参数。我复盘第一次大促事故时发现，当时我们只盯着QPS看，忽略了TP999和资源饱和度，结果就是QPS看着还能扛，实际服务已经卡得不行了。
容量评估我建议重点看三个参数：一是接口的预估峰值QPS，这决定了服务实例数的下限；二是TP999耗时，这决定了用户体验的下限，当TP999超过800毫秒，说明系统已经进入过载状态；三是CPU和内存的资源饱和度，当CPU超过70%持续三分钟以上，就要开始准备扩容或者限流了。
我们在Kubernetes上配置了HPA（水平自动扩容），指标就是CPU使用率，阈值设置为60%。但这里有个坑，HPA扩容有冷启动时间，通常需要两到三分钟Pod才能就绪，所以纯粹依赖自动扩容应对瞬间尖峰是不现实的。我们最终的方案是“预测式扩容 + 弹性伸缩兜底”：大促前两小时预先把Pod数量扩到预估值的1.5倍，大促开始后HPA根据实时流量继续扩容，如果QPS超过预估值的80%就触发预设的告警。
3. 高并发流量治理实战：Sentinel限流、熔断与热点防护
3.1 为什么选择Sentinel而不是其他限流组件
限流组件选型是我们做出的一个关键决策。当时市面上主流的方案有Google Guava RateLimiter、Hystrix，以及阿里开源的Sentinel。我们的场景是微服务架构，流量治理需要跟Spring Cloud Alibaba生态深度集成，所以最终选择了Sentinel。现在回头看，这个选择做对了，Sentinel在流量治理上的能力边界远超单纯的限流工具。
Sentinel最核心的价值在于它提供了“流量控制、熔断降级、系统负载保护”三位一体的能力。限流解决的是流量过大的问题，熔断解决的是下游依赖故障的问题，系统负载保护解决的是整体资源水位过高的问题。三者配合使用，才能在复杂的高并发场景下构建一个完整防线。
具体到我们的业务场景，有三类规则是必须要配置的。第一是QPS限流规则，针对核心接口设置单机阈值；第二是线程数限流，防止慢调用拖垮整个线程池；第三是熔断规则，当下游服务的错误率超过阈值时，快速切断调用链路。
3.2 从Agent接入到规则下发的Sentinel落地全流程
接入Sentinel我们分了四步走。第一步是在Spring Boot项目中引入依赖，因为我们已经用了Spring Cloud Alibaba这一套，所以接入非常丝滑，只需要在pom.xml里加上sentinel-spring-cloud-gateway和sentinel-annotation-aspectj依赖。第二步是简单的代码埋点，核心接口加上@SentinelResource注解，blockHandler用于处理被限流的请求，fallback用于处理业务异常。第三步是配置规则，我们用的方式是把规则下发到Nacos上，Sentinel客户端通过Nacos数据源动态读取规则，这样每次调整限流阈值不需要重启服务。第四步是上线前验证，在压测环境把流量打到阈值附近，确认限流逻辑生效且返回信息友好。
下面是一个核心交易接口的Sentinel使用示例，这是我们从库存扣减接口上抽取出来的简化版本，运行逻辑和线上配置保持了一致：
@SentinelResource( value = "stock:deduct", blockHandler = "handleBlock", fallback = "handleFallback" ) public boolean deductStock(Long skuId, Integer count) { // 库存扣减核心逻辑，走Redis预扣 + 异步DB对账 return stockService.deduct(skuId, count); } public boolean handleBlock(Long skuId, Integer count, BlockException ex) { // 被限流时的兜底逻辑，直接返回客户端友好提示 log.warn("库存扣减接口被限流，用户稍后重试"); return false; } public boolean handleFallback(Long skuId, Integer count, Throwable ex) { // 业务异常兜底逻辑，记录详细日志方便排查 log.error("库存扣减接口异常", ex); return false; }这段代码看起来简单，但有几个细节值得注意。第一，blockHandler处理的是被Sentinel拦截的情况，比如限流和熔断都走这里，而fallback处理的是业务代码自身的异常，两者千万不要搞混，一旦写反了会出现限流信息返回不友好的问题。第二，value属性必须全局唯一，命名规则建议用“服务名：接口名”的格式，否则规则下发时会出现覆盖错乱的情况。第三，兜底逻辑里要学会做取舍，像库存扣减这种核心操作，被限流时不要做复杂处理，直接返回“稍后重试”即可，避免在限流场景下又引发新的资源消耗。
3.3 电商大促下的限流规则细节：阈值怎么算，参数怎么调
限流规则配置是Sentinel使用中最需要细心的地方。阈值设置不是拍脑袋来的，我建议按照“预估峰值QPS / 服务实例数 / 冗余系数”来倒推。举个例子，一个接口预估峰值QPS是4万，部署了20个实例，冗余系数取0.7，那么单机阈值就是40000 / 20 / 0.7，大约是2857。这个公式的核心逻辑是：假设流量在实例间均匀分布，同时给每台机器留出30%的冗余能力应对突发波动。
在电商场景里，光有普通的QPS限流还不够，热点参数限流是必须做的。大促期间一定会出现几个超级爆款SKU把整个接口的QPS吃光的情况，其他正常商品全部被连累。我们在Sentinel里专门为商品查询和库存扣减接口配置了热点参数限流规则，参数索引为商品ID，单机阈值设置为每秒200，如果商品ID落在了热点参数例外项里（一般是预判的爆款ID列表），阈值降为每秒50。这样爆款再怎么热，也只能占用固定配额，不能影响其他商品。
熔断规则同样关键，尤其是对下游依赖的保护。我们的订单服务依赖支付回调、库存服务和会员服务，任何一个下游出问题都可能拖垮订单线程池。Sentinel的熔断规则我们配置的是慢调用比例模式：当接口的TP999超过500毫秒的请求占比超过30%，触发熔断，熔断时长10秒。这个参数是经过压测验证的，既不会因为偶发波动就频繁熔断，又能在真正故障时做到快速隔离。
3.4 集群流控与自适应限流：解决分布式限流不均的问题
单机限流有一个天然缺陷——流量在实例间分布是不均匀的。一台机器都堵到限流阈值了，另一台机器可能还很空闲。尤其在K8s环境下，每次Pod重建IP都变，负载均衡策略不可能是完美哈希。这个问题在第七次告警时彻底暴露出问题：某个商品详情接口的预估峰值是5万QPS，20个实例单机阈值设为2500，结果流量分布不均，有5台机器QPS飙到4000被限流大量报错，另外15台机器只有1500左右。
这个问题的解决方案是Sentinel的集群流控能力。集群流控的思路是把限流判断从单机维度提升到集群维度，通过一个Token Server统一管理整个集群的流量配额。我们在商品详情和搜索这类无状态接口上启用了集群流控，设置集群总阈值5万，单机最大阈值2000。这样即使流量在实例间分布不均，只要集群总流量没超过5万就不会触发限流。
不过集群流控也不是银弹。Token Server本身是一个独立部署的组件，如果它挂了，所有依赖它的限流判断都会失败。我们的做法是开启Sentinel的Fallback到本地单机限流的能力，当Token Server调用异常或超时后，自动降级为本地限流规则，保证在极端情况下服务仍然有最基础的自我保护能力。另外，Token Server的部署一定要独立于业务集群，否则业务流量高峰正好也是它压力最大的时候，容易一起出问题。
4. 数据层的高并发治理：从缓存击穿到数据一致性
4.1 缓存穿透、击穿、雪崩：三个名字相似但解法完全不同的问题
如果说流量入口的治理是第一道防线，那数据层就是第二道防线，而且这道防线一旦被击穿，影响面往往更大。四年里我们有三次告警直接或间接跟缓存有关。所谓缓存穿透，指的是查询一个一定不存在的数据，请求直接打到数据库上，每次都要查库，缓存形同虚设。电商里的典型场景是用户查询一个已下架或被删除的商品SPU ID，这类请求会在短时间内集中把数据库打垮。
我当时做了两个决策来应对穿透：一是对空值做短时间缓存，缓存时间为60秒，虽然理论上有短暂的窗口期，但能挡住99%的无效请求；二是在网关层和业务层同时加了布隆过滤器，把所有有效商品ID在活动开始前预热进过滤器，查询时先过布隆过滤，不存在就直接返回。
缓存击穿和穿透只有一字之差，但问题完全不同。击穿针对的是热点的缓存Key在过期的一瞬间，大量请求同时涌入数据库。每次大促期间，商品详情缓存一旦过期，因为缓存重建时间需要100毫秒左右，这100毫秒里如果有5万并发同时查这个Key，数据库就被打爆了。解决方案是加分布式锁，只允许一个请求真正去查数据库重建缓存，其他请求等待锁释放后再从缓存里拿。
缓存雪崩就更麻烦了，大量缓存Key在同一时间过期，数据库瞬间被海量请求淹没。这通常是技术决策错误导致的——很多团队设置过期时间喜欢用固定值，比如所有商品缓存都设为30分钟，结果整点一到全部失效，数据库就遭殃了。我们的解法是过期时间加上一个随机偏移量，把过期时间打散在30到45分钟之间，同时给核心数据做永不过期缓存，由后台定时任务主动刷新。
4.2 热点Key识别与本地缓存多级组合：一次雪崩事故的复盘
第三次告警是一次典型的热点Key导致的集群雪崩。当时我们上线了一个限时五折活动，活动页把某个爆款SKU的信息推给了数百万用户，所有用户几乎同时点击查看这个SKU的详情。这个SKU的缓存Key在Redis集群里就落在同一个分片上，瞬间QPS超过两万，直接把那个Redis分片打挂。Redis集群分片挂掉后，缓存不可用，所有请求全部穿透到MySQL，数据库连接池被瞬间耗光，整个商品服务不可用。
那次事故之后，我做的技术决策是两级缓存架构。第一级是Caffeine本地缓存，缓存在每台业务机器内存里，过期时间10秒，容量上限10万条，LRU淘汰。第二级是Redis分布式缓存，过期时间30到45分钟随机。查询链路先查本地缓存，没命中再查Redis，Redis没命中才查数据库。热点Key在这个架构下，绝大多数请求在本地缓存这一层就被挡住了，Redis分片的压力大幅下降。
热点Key的识别我们用了两种手段。一种是业务规则预判，运营活动开始前把所有参与活动的SKU标出来，提前在本地缓存预热。另一种是在线自动识别，通过Sentinel的热点参数统计能力，统计一段时间内的热点参数排名，把排名前100的参数自动推送到各服务的本地缓存里。实测下来，两级缓存架构把热点Key打挂Redis的概率降到了原来的十分之一以下。
4.3 数据库连接池与慢SQL治理：把数据库扛量能力拉满
数据库层面的高并发治理容易被忽略，但它恰恰是最需要提前布局的一环。依赖缓存确实能挡住大量读请求，但订单写入、库存扣减这类写操作最终还是要落到数据库上。我们有两次告警直接跟数据库慢查询有关，而且排查下来SQL本身并不复杂，就是连接池的配置和索引没跟上流量增长。
数据库连接配置上有几个容易被忽视的参数。第一个是maxActive和maxWait，最大连接数设置过小会导致请求排队，设置过大又容易拖垮数据库，我们线上的经验是单库最大连接数控制在50以内，连接等待超时设置为3秒，宁可等不到就报错，也不要让请求无限阻塞。第二个是连接空闲超时时间，必须要小于数据库侧的wait_timeout，否则会频繁出现connection is not available的报错。第三个是PrepareStatement缓存，这个参数在MySQL驱动下一定要开启，cachePrepStmts=true，否则同一个SQL每次都需要重新解析，在高并发下CPU消耗非常明显。
慢SQL治理我们建了一个在线上的执行计划巡检任务，每十五分钟扫描一次慢查询日志，把超过500毫秒的SQL全部抓出来，分析执行计划，强制要求开发在索引不达标的情况下不允许上线。举个例子，订单表是按用户ID分库分表，但运营后台经常按商户ID查询订单列表，一开始没建商户ID索引，流量一大这个查询就把数据库拖垮。加了联合索引后，同样的查询耗时从2秒降到30毫秒。看似一个小改动，在高并发下就是生与死的差别。
5. 全局高并发韧性：告警治理、流量调度与故障演练
5.1 告警治理：把“狼来了”变成真正有价值的信号
十次P0级别告警之外，我们收到的普通告警其实有上千条。告警泛滥最大的问题是会让人变得麻木，真正出大事时反而没人重视。第四次告警后，我专门花了两周时间做告警治理，核心原则是三个：告警必须可执行、告警必须分级别、告警必须去重。
可执行的意思是，每一条告警都得告诉值班的人应该做什么，比如“商品服务QPS超过阈值”这种告警就没有可执行性，收到也不知道该怎么做。我们把告警改成“商品服务QPS超过阈值，请立即查看是否触发限流规则，如果限流命中率超过30%请联系商品服务负责人确认是否需要扩容”。分级别就更简单了，P0是服务不可用，需要立即拉起电话会议；P1是功能受损，需要在15分钟内响应；P2是一般异常，只需要记录在日报里跟盯。去重消息我们做了聚合，同一个服务在一个窗口期内的同类告警只发一条。
现在回看那十次告警，真正需要人工介入的其实只有三次，其余七次都是预案自动处理了。这个过程就是高并发治理的成熟度在提升：从最开始全人工救火，到后来半自动降级，再到现在的自动化预案为主、人工介入为辅。
5.2 容量自动伸缩与多区域流量调度：K8s与Sentinel的配合
多区域部署和流量调度是海外电商平台特有的复杂场景。欧美和东南亚用户的活跃时间段完全不同，如果两个区域的服务完全孤立，资源利用率和容灾能力都会打折扣。我们把整个平台按区域分为两个大的K8s集群，中间通过网关层实现跨区域流量调度。当东南亚大促流量飙升导致服务过载时，网关会把一部分读流量打到欧美集群的只读副本上。
这个方案前期依赖一个关键的架构决策：接口的读写分离要彻底。只有读接口能跨区域调度，写接口必须留在本区域处理，否则就会面临分布式事务的难题。我们在API网关上对每个接口做了标注，带READ标签的接口允许跨区域路由，带WRITE标签的接口一律本区域处理。限流规则也做了区域维度的配置，Sentinel集群流控的Token Server部署在中心集群，拉美和东南亚的业务集群都从这个中心Token Server申请配额。
自动扩缩容这块，我们最终没有用K8s内置的HPA，而是用了一个基于自定义指标的弹性伸缩方案。核心原因是电商的流量尖峰来得太快，CPU指标有滞后性，等CPU升高到阈值时流量已经打到服务上几十秒了。我们的方案是直接用网关层统计的QPS指标作为弹性伸缩的触发条件：当某个服务的QPS在五分钟内增长超过50%时，立即触发扩容任务，提前把新Pod拉起来，同时在注册中心做好预热。一个服务实例的启动时间我们优化到40秒以内，加上流量预热，基本能在流量真正到达前完成扩容。
5.3 故障演练与应急预案：四次真实故障教会我的事
高并发系统有一句老话：系统不是在连续运行中出问题的，而是在变化中出问题的。变化包括新版本上线、配置更改、流量突增、依赖变更。我们几乎每一次事故都跟“变化”有关。所以从第五次告警开始，我把故障演练提到了和功能开发同等重要的优先级。
故障演练的做法是每个月挑一个非高峰时段，在预发环境或者低峰期的生产环境里手动注入故障，比如把Redis某一个分片直接kill掉、模拟下单服务延迟三秒、给某一个微服务注入网络丢包。然后看整个系统的表现：限流有没有生效，熔断有没有触发，降级预案有没有自动执行，监控告警有没有在预期时间内发出。我们最夸张的一次演练是把核心数据库的磁盘写满，然后用一天时间复盘整个过程，把预案文档从一页纸扩展成了三十页的详细操作手册。
为了确保故障演练自身安全，我们做了一个准入条件：演练前必须经过架构评审，演练全程有单独的可回滚开关，演练时间严格控制在半小时以内。这些规则看起来很繁琐，但正是这些演练，让团队在真正的故障来临时能够做到冷静、有序。后来第八次告警时，面对一个之前从没遇到过的缓存集群雪崩，我们依靠事先写好的降级脚本，在五分钟内完成了核心链路降级，把影响面控制在了可接受范围内。
5.4 高并发治理的决策复盘：几十个技术选型背后的思考框架
四年的时间里，我们做了几十个技术决策，每一个都踩过坑，也都有值得记录的思考。如果把这些决策背后的逻辑压缩成一句经验，那就是：高并发方案的选择不是选最好的，而是选最匹配的。
关于选型匹配度，我举个最直接的例子。先用限流组件，我们对比过Guava RateLimiter、自研限流和Sentinel。Guava的单机限流能力很强，但完全没有集群维度，分布式场景用不了；自研限流要处理数据一致性、高可用、控制台等一堆问题，投入产出比太低；Sentinel能同时覆盖限流、熔断、热点防护、集群流控，还跟Spring Cloud Alibaba无缝集成，最终选择它就是一个匹配度的结果。
再看看缓存架构，纯Redis分布式缓存是标准方案，但对热点Key场景不够用，所以我们加了本地缓存做多级缓存。服务间调用用同步Feign在链路短时没问题，但链路一长就必须改成RocketMQ异步解耦。数据库分库分表用ShardingSphere，当时也对比过MyCat，因为我们的场景是偏OLTP、需要强一致性的订单库，ShardingSphere的分布式事务方案更成熟，所以选了它。这些决策没有一个是一拍脑袋决定的，背后都是拿真实流量数据、真实压测结果来对比验证的。
一致性方案上，最核心的一课是：能异步就不要同步，最终一致能接受就不要强一致。我们在库存和订单链路里一开始想用分布式事务保证强一致，压测时发现分布式事务在高并发下性能瓶颈非常明显。后来改成了事务消息加本地消息表的最终一致方案，性能提升了三倍，而业务上淘宝、京东等平台本来就是这么做的，用户根本感知不到那几十毫秒的差异。
数据同步这块，为了让搜索推荐和数据仓库拿到交易数据，之前也是用定时任务批量同步，一到高峰期就跟业务抢数据库资源。后来改成基于Binlog的增量同步，用中间件把数据推到MQ里，消费端再写入数据仓库。这个改动把一个跑了两年的定时任务彻底干掉，数据库整体负载下降了将近20%。
每次复盘我都习惯画一张决策树：什么问题、有哪几个候选方案、为什么选这个不选那个、方案的边界条件是什么、如果失效了备选方案是什么。这套思考框架让我在面对新问题时，不用每次从零开始推演，而是能基于历史决策快速找到最优解。
6. 四年的经验沉淀与实用建议
回到文章开头那句话，从半夜被电话叫醒，到后来能在告警信息弹出后冷静判断要按哪个预案执行，这中间差的不是技术能力，而是对系统全貌的理解和对异常流量的敬畏。
我个人这四年最深的体会有三点。第一，高并发治理的优先级排序永远是“先保核心链路，再保非核心体验”。每次大促前我们都会提前列一份清单，哪些接口必须扛住，哪些接口可以被限流被降级，这份清单是整个治理体系的起点。第二，任何限流熔断的参数都不是配完就不管的，流量模型在变，业务在增长，参数必须跟着调整。我在项目里专门排了一个“每月调参日历”，定期复盘所有限流阈值和熔断参数是否需要调整。第三，不要试图用一个方案解决所有高并发问题，缓存、限流、熔断、异步、扩容，每一类工具都有它最适合的场景，组合使用才是高并发治理的正确姿势。
如果仔细去看那十次告警的演变轨迹，会发现一个明显的规律：前几次告警是架构设计层面的缺陷，后面几次告警开始变成配置和预案执行层面的问题，到了最后两次告警，问题已经演变成对极端场景的覆盖不足。这个变化本身就说明，高并发治理是一个不断逼近极限的过程，你永远无法彻底解决高并发问题，你能做的是不断提升系统的承受能力和容错能力，让每一次未知的流量冲击都落在你已经准备好的预案里。
从技术栈本身来说，Sentinel、Redis多级缓存、K8s弹性伸缩、RocketMQ异步化，这些都是市面上成熟甚至主流的方案。真正的区别在于怎么组合、怎么调参、怎么预防、怎么演练。这些细节没法一下子讲完，但希望这篇长文能给你一个相对完整的框架。如果你的系统正在经历高并发的阵痛，可以从告警复盘和容量评估入手，先把问题看全了再动手改方案。技术方案从来不缺，缺的是对问题本身的准确认知和面对流量时的战略定力。
