高并发这三个字做后端的人听到耳朵起茧但真正能把高并发场景下的保障措施讲清楚、落到实处的其实不多。前阵子我正好把一个核心交易系统从日均几万请求压到秒级上万QPS过程中把限流、熔断、降级、隔离、缓存、异步化这一整套组合拳完整过了一遍踩了不少坑也沉淀出一些能直接复用的经验。这篇就把高并发场景下最核心的保障思路和实战配置拆开揉碎了讲尤其会结合 Alibaba Sentinel 在微服务流量治理里的落地细节给正在做系统压测、容量保障或者准备接 Sentinel 的团队一个可参考的路径。这套东西适合谁如果你是负责核心接口稳定性、正在被突刺流量打挂过线上或者领导让你“把系统的抗压能力提上去”但不知道从哪下手这篇应该能帮你建立完整的保障框架。我会把原理、参数、配置、坑点都铺开不搞玄学全是能抄作业的内容。1. 高并发保障的整体思路先搞清楚系统是怎么被打挂的1.1 高并发场景下的三大典型故障模式先说个很扎心的现象大部分系统不是慢慢变慢的而是突然就崩了。我经历过一次典型的线上事故某个营销活动零点上线流量在30秒内涨了50倍数据库连接池瞬间被打满紧接着服务端出现大量超时超时又导致上游重试重试又放大了流量最后整个服务集群雪崩页面全部 502。事后复盘发现系统其实有缓存、有集群、有读写分离但缺了最关键的一道闸门——流量入口没有做任何保护。高并发场景下系统被打挂基本逃不出三种模式第一种是资源耗尽型。线程池被打满、数据库连接池被占满、内存被大对象撑爆属于硬资源被流量堆死。这种最直观但往往也是最难提前发现的因为你不知道流量峰值能到多少。第二种是级联故障型。一个下游服务慢了导致上游线程全部阻塞等待接着上游也跟着慢然后一路传染上去最后整个调用链全挂。这就是典型的雪崩效应Hystrix 当初就是为了解决这个问题才诞生的。第三种是热点集中型。某个商品、某个用户、某条数据突然变成热点单个缓存 Key 被疯狂读取单台机器网卡被打满而其他机器却闲着。这种问题最难处理因为普通的路由策略把流量分散了但热点 Key 的流量是没办法均匀分散的。这三种故障模式对应到保障措施上就是限流挡流量、熔断断故障、隔离控范围再加上缓存和异步化从源头削减压力。一套完整的高并发保障体系是在这些维度上同时发力而不是只靠某一个组件。1.2 保障体系的六大核心维度我把高并发保障体系拆成六个维度团队做技术方案时可以对着这个清单自查流量控制用限流算法对入口流量进行整形保证进入系统的请求量不超过系统的承载能力这是在“源头”保护系统。熔断机制当下游故障率达到阈值时快速失败不再继续调用下游避免故障级联放大这是在“调用链”上做保护。降级兜底当核心链路压力过大时主动牺牲非核心功能比如商品详情页的评论数、推荐位把资源留给核心交易链路。隔离容错通过线程池、信号量、分组等方式隔离不同业务之间的相互影响防止一个业务拖垮所有业务。缓存加速把热点数据放在离用户更近的位置减少对数据库的直接访问这是在“数据面”削峰。异步化把非实时的操作发短信、写日志、更新库存流水丢到消息队列里异步处理削峰填谷。这六个维度不是孤立的而是层层递进的关系。我习惯用“水坝”来类比流量像洪水限流是上游的拦水坝决定放多少水进来缓存和异步化是水库和分流渠把水先存起来慢慢放熔断和降级是泄洪闸水太大时主动放弃一些非核心区域保核心区域不被淹隔离则是把整个水系分成多个独立的水库一个溃堤不会淹掉全部。后面几章我会重点讲 Sentinel 在这个体系里承担的流量治理角色再补上实操配置、规则参数和生产落地细节。2. 流量治理的底层机制限流、熔断、降级的原理与选型2.1 限流算法对比从固定窗口到令牌桶Sentinel 用了哪种限流是整个高并发保障的第一道大门也是最容易用错的组件。很多团队接 Sentinel 或者 Guava RateLimiter配个 QPS 阈值就完事了其实限流算法的选择直接决定流控效果。我在生产中实际比较过四种主流算法各有优劣。固定窗口算法最简单把时间切成一个个窗口比如1秒每个窗口内允许通过的请求数是固定的窗口切换时计数器清零。但有个很明显的问题——临界突变。假设限制100 QPS第1秒最后100ms通过了100个请求第2秒开始100ms又通过了100个请求实际上200ms内打进来200个请求系统早就扛不住了。固定窗口算法就是这种“窗口边界容易被击穿”的缺陷。滑动窗口算法做了改进不是整秒切换而是把时间切得更细比如切成10个100ms的小格子随着时间推移窗口整体向后滑动统计最近1秒的请求数。这样能解决大部分临界问题但本质上还是计数器的思路无法做到均匀平滑的流量整形。Sentinel 的默认限流模式之一就是基于滑动窗口实现的适合大多数业务场景。漏桶算法和令牌桶算法都是平滑限流方案。漏桶的模型是一个固定容量的桶请求先进入桶里底部按固定速率漏出超过桶容量的请求直接丢弃。优点是流量绝对均匀缺点是无法应对突发流量。令牌桶则相反桶里装着令牌请求要拿到令牌才能通过令牌按固定速率生成但桶可以积攒令牌允许一定程度的突发。Guava RateLimiter 的平滑突发模式就是令牌桶思想。Sentinel 的底层限流统计采用的是滑动窗口它不是纯令牌桶也不是纯漏桶而是结合了计数器统计和流量整形策略。实际配置时如果你的接口能容忍突发用默认的快速失败模式即可如果下游数据库只能承受匀速写入那就用匀速排队模式对应漏桶思想。我在生产环境里通常是读接口用快速失败写接口和调用外部慢服务的接口用匀速排队。来看一段 Sentinel 的限流规则配置这是我在一个订单查询接口上实际用过的配置// 订单查询接口限流单机 QPS 500超出直接快速失败 FlowRule flowRule new FlowRule(); flowRule.setResource(order-query-api); flowRule.setGrade(RuleConstant.FLOW_GRADE_QPS); flowRule.setCount(500); flowRule.setLimitApp(default); // 快速失败模式超出的请求直接拒绝 flowRule.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_DEFAULT); FlowRuleManager.loadRules(Collections.singletonList(flowRule));提示setControlBehavior这个参数很容易被忽略但它恰恰是最影响用户体验的。快速失败模式下客户端会直接收到异常必须在网关层统一处理成友好的提示信息而不是把异常堆栈抛给前端。2.2 熔断与降级的配合逻辑什么时候断、什么时候降熔断解决的是“下游已经不行了上游别再打了”的问题。我见过不少团队把熔断做成“单纯的下游异常统计”比如下游调用失败率超过50%就熔断但这样有一个很大的盲区——只统计了异常没有统计慢调用。慢调用对系统的伤害往往更大因为线程会一直阻塞等待逐步耗尽线程池。Sentinel 的熔断策略要注意MaxAllowedRt这个参数的设定。我遇到过这样一个案例一个下游接口平时响应50ms但网络抖动时响应时间变成5秒由于并没有抛异常错误率其实是0如果只配置了异常比例熔断根本不会触发。后来改成慢调用比例熔断设置最大RT为500ms、比例阈值0.5、最小请求数20抖动一旦持续熔断立刻生效这才把上游线程池保住。熔断器的状态机是经典的关闭 → 打开 → 半开 循环。关闭状态正常放行流量打开状态直接快速失败不调用下游半开状态允许少量探测请求通过看下游是否恢复如果恢复了就关闭熔断器否则重新打开。这里有个容易被忽略的细节半开状态下放行的探测请求数量决定了恢复速度。放少了恢复慢放多了故障中的下游可能又被压垮。Sentinel 的MaxHalfOpenRetryNum配置半开状态允许的探测请求数默认是1生产环境我一般调到3到5太低会导致恢复期过长太高在极端故障下会给下游补一刀。降级和熔断是一对孪生兄弟。熔断是“完全断掉”而降级则是“换一条路走”。比如商品详情页里推荐位接口超时了降级方案就是直接返回一个空列表库存接口挂了降级方案可以用缓存里的库存数据兜底哪怕库存数字不是实时精确的也比用户看到报错强。降级的关键是必须在设计阶段就准备好降级预案而不是等线上出问题了再写降级逻辑。我总结了一套降级的分级策略在团队内部推广后效果不错一级降级非核心功能直接关闭评论、点赞、推荐位适合大促预热期主动执行。二级降级核心功能简化返回商品信息用缓存、库存给预售数据适合流量高峰时段。三级降级保命降级只保留交易链路的最小可用集合下单、支付其他入口全部关闭。生产上配置熔断降级规则时建议一步一步来。别一来就上很高深的动态规则推送先在控制台手工配置观察一两个大流量周期再沉淀成代码里的规则文件最后才接配置中心做动态推送。跳过这个循序渐进的过程我见过有团队直接在配置中心批量推送规则结果规则有误导致大规模误熔断线上事故反而更严重。3. Sentinel 实战从接入到规则落地的完整路径3.1 Spring Cloud Alibaba 快速接入 Sentinel 的完整步骤Sentinel 是阿里开源的流量防卫组件它的定位就是微服务场景下的流量治理。相比 HystrixSentinel 的优势在于支持实时监控控制台、规则可以动态生效、细粒度的资源定义、对 Spring Cloud Gateway 和 Dubbo 都有现成的适配。我们项目从 Hystrix 迁移到 Sentinel 后最大的感受就是规则调整不用再发版了直接在控制台改完推下去几秒钟就生效。接入分三步走。第一步加依赖。如果用的是 Spring Cloud Alibaba直接引入 Sentinel 的 starter 就能和 OpenFeign、RestTemplate 这些组件自动整合dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-sentinel/artifactId version2021.0.5.0/version /dependency第二步配控制台地址。在application.yml里加上 Sentinel 控制台的连接信息同时把 transport 端口默认是8719开放出来spring: cloud: sentinel: transport: dashboard: 192.168.1.100:8080 port: 8719第三步定义资源。Sentinel 里的“资源”可以理解为你想要保护的一个入口比如一个接口、一个方法、一段代码块。最常见的做法是直接在 Controller 方法上加注解RestController public class OrderController { GetMapping(/order/detail) SentinelResource(value order-detail-api, blockHandler detailBlockHandler, fallback detailFallback) public OrderDetail detail(RequestParam Long orderId) { // 核心业务逻辑 return orderService.getDetail(orderId); } // 限流/熔断触发时进入的方法注意参数要和原方法一致再追加一个 BlockException public OrderDetail detailBlockHandler(Long orderId, BlockException ex) { return OrderDetail.degradedOrder(); } // 业务异常时的兜底方法 public OrderDetail detailFallback(Long orderId, Throwable t) { log.error(order detail error, orderId{}, orderId, t); return OrderDetail.degradedOrder(); } }这里有个特别容易踩的坑blockHandler方法的参数列表必须和原方法一致并且在末尾追加一个BlockException参数否则启动时就会报错。另外SentinelResource注解只对限流、熔断等系统保护生效如果业务代码本身抛出异常默认不会走 fallback需要单独配置fallback属性。如果想两者都处理blockHandler处理流控触发fallback处理业务异常两个可以同时配置。3.2 核心规则配置与参数解读生产实践接入 Sentinel 只是开始真正的工作量在规则配置。我把生产环境最常用的三类规则拆开讲都是踩过坑之后总结出来的。流量控制规则是最基础的。核心参数是resource资源名、count阈值、grade限流维度QPS 还是并发线程数、controlBehavior限流效果。生产上我一般优先用 QPS 做限流维度因为它直观、好评估。并发线程数限流适合那种“单请求耗时长、系统线程资源珍贵”的场景比如调用外部 AI 接口单个请求可能要好几秒这时候用并发线程数限流能避免大量线程被慢请求占住。配置阈值的时候不要拍脑袋定数字要通过压测拿到系统真实承载能力再乘以 0.7 到 0.8 作为安全阈值。举个例子压测发现订单查询接口在单机 4C8G 的配置下最大能扛住 800 QPS那生产配置就设成 600留出 25% 的缓冲区间防止流量毛刺直接打满。熔断降级规则里的三个参数需要重点解释grade熔断策略分别是慢调用比例、异常比例、异常数。日常用的最多的是慢调用比例和异常比例。count触发阈值。慢调用比例模式下这个是最大 RT单位毫秒超过就算一次慢调用异常比例模式下这个是异常比例比如 0.5 表示 50%。timeWindow熔断时长单位秒。熔断打开后持续多久进入半开状态。这个数值要根据下游故障的平均恢复时间设置如果下游是一个依赖数据库的接口数据库故障恢复可能需要一两分钟熔断时长设成 30 秒可能还没等数据库完全恢复就放流量进去了又触发一次熔断。我一般建议设成 60 秒起步。下面这套是我在订单支付链路下的降级规则配置可直接参考DegradeRule degradeRule new DegradeRule(); degradeRule.setResource(order-pay-api); // 慢调用比例模式 degradeRule.setGrade(RuleConstant.DEGRADE_GRADE_RT); // 最大 RT 为 300ms超过即算慢调用 degradeRule.setCount(300); // 慢调用比例触发阈值 degradeRule.setSlowRatioThreshold(0.6); // 最小请求数防毛刺误触发 degradeRule.setMinRequestAmount(20); // 熔断时长 60 秒 degradeRule.setTimeWindow(60); // 半开状态下允许探测请求数 degradeRule.setMaxHalfOpenRetryNum(3); DegradeRuleManager.loadRules(Collections.singletonList(degradeRule));注意有一个常见的误配置是setMinRequestAmount设得太小。默认是5但在低流量场景下比如凌晨订单少5个请求里只要有3个慢调用就会以60%的慢调用比例触发熔断这就是典型的数据量太少导致的误判。生产上这个值我最低设到20。系统保护规则是 Sentinel 的另一个特色它不针对某个具体接口而是面向整个系统的自适应保护。核心思路是根据系统的 Load、RT、线程数、入口 QPS 等维度自动判断系统是否处于危险状态如果是就限制入口流量。我建议在入口网关或核心服务上打开系统保护设置一个合理的最大 Load 阈值比如 4 核机器设成 5这样即使某个接口没有配置限流规则系统整体压力过大时也会自动拦截起到兜底作用。3.3 规则持久化不接配置中心重启就白配了新手用 Sentinel 最容易踩的坑是在控制台上手工配置了一堆规则验证没问题开心地下线。结果第二天服务一重启所有规则全部消失。因为默认情况下Sentinel 的规则是存在内存里的控制台改完只是推送到应用内存并没有持久化到任何存储。生产环境必须接入持久化方案。Sentinel 官方提供了文件、Nacos、Apollo、ZooKeeper 等多种数据源适配。我们团队用的方案是 Nacos因为配置中心本来就在用Sentinel 规则可以当作一种 Nacos 配置来管理改配置不用重启服务还能和配置中心已有的审计、灰度能力打通。核心配置写法是加一个SentinelDataSource的 BeanConfiguration public class SentinelNacosDataSourceConfig { Bean public DataSource flowDataSource() { String dataId sentinel-flow-rules; String groupId DEFAULT_GROUP; Properties properties new Properties(); properties.setProperty(serverAddr, 127.0.0.1:8848); properties.setProperty(dataId, dataId); properties.setProperty(groupId, groupId); // flow 表示流控规则 return new NacosDataSource(properties, ConverterManager.loadConverter( com.alibaba.csp.sentinel.datasource.Converter, String.class, List.class)); } }接入 Nacos 数据源之后每次服务启动时会先从 Nacos 拉取最新规则后续 Nacos 上的变更也会自动推送到应用。这就不怕重启丢规则了规则变更也有了审计记录。关于规则装载器FlowRuleManager.loadRules、DegradeRuleManager.loadRules这些入口在持久化场景下不需要手动调数据源会自动回调更新代码里避免重复调用导致规则被覆盖就行。4. 高并发保障的另一半配套手段才是最终胜出的关键4.1 缓存与异步化从源头削峰别把所有压力都丢给限流限流、熔断是做“防守”但高并发系统光靠防守是不够的防守做到极致也只是保证系统不死真正让系统在大流量下还能丝滑响应的是缓存和异步化这套“进攻”手段。先聊缓存。我接手过一个详情页接口QPS 峰值能到 3000所有流量打到 MySQL 上数据库 CPU 直接 100%。加了 Redis 缓存后命中率做到了 95% 以上数据库 QPS 降到 100 左右限流阈值都从 800 降到了 200。这就是缓存的价值——你根本不需要无限扩容只要把热数据挡住系统压力自然就降下来了。缓存不是随便加就完事的三个问题必须解决第一是缓存击穿。某一个热点 Key 突然失效大量请求同时去数据库查数据库直接被打爆。解决办法是缓存重建加锁让只有一个线程去查库并回填缓存其他线程阻塞等待。用 Redisson 的tryLock可以很干净地实现分布式锁。第二是缓存穿透。查一个根本不存在的 Key缓存没有数据库也没有每次请求直接打到数据库。经典的解决方案是布隆过滤器前置拦截另一个更省事的方案是把空结果也缓存起来过期时间设短一些比如 30 秒也能挡掉大部分无效流量。第三是缓存雪崩。大量 Key 在同一时间段集中过期数据库瞬间收到大量请求。解决思路有两个过期时间加随机偏移量让过期时间分散或者用多级缓存Redis 挂了还有本地缓存兜底。再聊异步化。有些操作根本不需要在请求线程内同步完成比如下单后发短信、写操作日志、更新商品销量、通知运营系统这些全都应该丢到消息队列里去异步处理。把一次请求里耗时的非核心操作异步化接口 RT 能从 200ms 降到 50ms线程池占用率也能下降一大截系统的整体吞吐自然上去了。异步化的核心原则是核心链路不能依赖非核心系统的处理结果。比如下单操作订单主流程应该只写订单表和扣库存发短信、推送、更新搜索引擎索引这些统统异步化。如果消息队列挂了不能影响订单主流程的正常执行最多就是短信晚发一会儿这是可以接受的代价。这是我反复强调设计原则的原因异步化不仅仅是技术手段更是梳理业务核心边界的契机。4.2 线程池隔离与容量预估公式高并发场景下线程池隔离是防级联故障的物理隔离手段。线程池隔离的思想是不同接口、不同下游服务的调用走不同的线程池一个线程池的资源耗尽不会影响其他线程池。我用一个具体例子来解释一个服务里同时调用了用户服务和库存服务如果两个调用共用一个线程池库存服务变慢会把线程池占满用户服务的请求全部排队整个服务就废了。如果拆成两个独立的线程池库存服务的线程池慢了用户服务的线程池照样能处理请求。Sentinel 不像 Hystrix 那样强制用线程池做隔离它默认用信号量隔离并发线程数限流。信号量隔离更轻量不增加线程上下文切换开销适合大部分场景。但如果你有一个极端场景比如某个下游服务非常慢且不可控线程池隔离是更安全的方案。在 Sentinel 中做线程池隔离可以给慢服务单独配置一个线程池在调用时用ThreadPoolExecutorexecute同时对线程池设置拒绝策略满了直接抛异常走降级逻辑。容量预估是保障措施里最容易被忽视的一环。做容量规划时我一般用这个公式算单机支撑 QPS 1000 / 单请求平均 RT再乘以单机可用线程数。举例接口平均 RT 是 100ms单机分配 200 个工作线程那单机理论最大支撑 QPS 是1000 / 100 * 200 2000。但实际上线程不可能 100% 都在干活要留出 GC、网络抖动、日志写入的开销所以再乘一个 0.7 的冗余系数得出单机安全 QPS 是 1400。集群 10 台机器整体容量就是 14000这时把限流总阈值设在 12000 左右同时保证单机限流在 1400 以内就能做到均匀分布。这个公式的价值不在于算出精确数字而在于让你明白一个道理提升高并发容量要么缩短 RT要么增加线程数要么加机器。限流规则必须基于容量评估结果来设否则就是无根之水。5. 生产环境常见问题与排查技巧实录5.1 规则不生效80% 是资源名对不上Sentinel 用得多了就会发现好多人反馈“我配置了限流怎么不生效”最后排查下来 80% 都是资源名不匹配。Sentinel 的资源名就是一个普通字符串控制台配置的resource必须和代码里SentinelResource注解的 value 完全一致大小写、空格都不能差。有一个项目代码里写的是order-detail-api控制台配的是orderDetailApi限流当然触发不了。排查这个问题的快速方法是在控制台的“实时监控”页面找到你要保护的接口看它有没有独立的资源链路。如果这个接口的调用量在监控页面上显示的是汇总到其他资源里了那就说明资源定义有误。还有一种情况是用了通配符路径比如/order/{id}Sentinel 默认不解析路径参数所有路径会被当成同一个资源需要手动在UrlCleaner里做归一化处理否则会按不同 URL 各算各的限流闸门形同虚设。5.2 高频毛刺与误限流阈值设置的艺术系统上线限流后最怕的不是流量被挡住而是正常流量被误杀。这种情况有个典型特征监控上看平均 QPS 才 300但限流配置是 500按理说不应该触发可偏偏时不时就出现几条限流日志。原因是“平均”掩盖了毛刺虽然平均 QPS 300但某一瞬间可能突然冲到 800。针对这种场景我的调优经验是不要把阈值卡死在一个精确值上要结合压测数据留出 25% 到 30% 的余量。同时根据接口的重要程度选择不同的限流效果重要接口下单、支付用快速失败宁可丢弃边缘流量也不能让核心流程图阻塞。一般查询接口用 Warm Up 预热模式让流量在冷启动阶段逐渐上升避免刚启动就被限流打死。写接口/慢下游调用用匀速排队模式让请求排队匀速通过保护下游数据库。如果是大促等场景有明确的流量预估可以在活动前提前压测、提前配好规则别等活动开始了再现场调阈值。我在大促前一般会做三轮压测第一轮测基准容量第二轮带着限流规则测第三轮做故障演练——人为kill一台机器、模拟数据库抖动看看限流熔断是否按预期触发。5.3 故障演练保障措施上了线不等于万事大吉最后说一下我在团队里强制推行的一个习惯故障演练。很多团队接完 Sentinel规则配好了控制台也连上了就以为高并发保障工作结束了。其实规则搭没搭对、参数配得合不合理、降级逻辑有没有写对只有真刀真枪演练过才能验证。我们每次大促前必做的演练清单包括先模拟单机故障。手动杀掉一台应用节点观察流量是否自动转移到其他节点限流阈值是否会自动调整如果是集群限流还要验证令牌是否重新分配。再模拟下游慢调用。用一个测试工具把用户服务的响应延迟提升到 3 秒观察 Sentinel 熔断是否触发降级方法是否被正确调用有没有把降级后的空数据返回给前端。最后模拟流量突刺。用压测工具持续抬高 QPS超过限流阈值 20%观察被拦截的请求是不是返回了友好的提示而不是一堆让人看不懂的异常堆栈。演练过程中发现的问题大多数是规则配置不符合真实场景、降级方法因参数不匹配导致启动报错、或者返回信息不友好。这些问题如果不演练是根本发现不了的等到线上真出了故障再发现就晚了。从我个人的角度看高并发保障根本不是“装一个组件、配几条规则”这么简单它是从架构设计、容量评估、规则配置到故障演练的一整套闭环。Sentinel 给了我们趁手的工具但使用工具的人得对系统有足够深入的理解。如果这些内容能帮你在自己的系统里少踩几个坑把高并发保障从口号落到实处那这篇就值了。