-
我给接口加了限流、限定每分钟最多 600 次以为稳了,大促时下游服务还是被瞬间打爆雪崩,我反复确认限流配置数字没错、监控里平均 QPS 也没超百思不得其解,最后才发现是我用的固定窗口计数器在每分钟切换那一瞬间放进了两倍流量的深度复盘
我的服务前面挡着一层限流:统计每分钟进来多少请求、超过 600 个就拒绝、下一分钟清零重数,我对它很放心。可大促当晚下游连接池瞬间被占满、超时、连锁雪崩,而限流明明开着。我盯监控,每分钟请求量几乎都贴着 600 的线没哪分钟超过,拒绝计数也在涨说明它确实在拦,可下游就是被打爆了。我怀疑下游容量缩水、怀疑配置被改大,都没有。直到把被打爆那一刻精确到秒的请求时间戳拉出来按秒画图才倒吸凉气:某一分钟最后…- 0
- 0
-
一个被高频访问的热点缓存恰好过期的那一瞬间,几千个请求同时扑向数据库去重建它,瞬间把数据库打垮了:一次缓存击穿、热点 key 过期空窗的深度复盘
我有个被高频访问的热点数据放在缓存里、设了 5 分钟过期,平时读缓存命中一切顺滑。可某次监控突然报警数据库 CPU/连接数瞬间飙满、差点雪崩,恰好发生在那个热点缓存过期的那一刻。复盘那一瞬间才明白这是缓存击穿:那个 key 被每秒几千请求高频访问,当它到点过期从缓存消失的瞬间,几千个并发请求同时发现未命中、几乎同时全部扑向数据库去查数据重建缓存,本该由缓存挡住的几千 QPS 在这一瞬间全砸到数据库…- 0
- 0
-
我给接口加了"每分钟最多 100 次"的限流,结果它还是在某个瞬间被 200 次请求打穿了,我对着固定窗口限流的临界问题排查了大半天的复盘
给核心接口加限流保护,用了最直观的固定时间窗口算法——每分钟一个计数器超100就拒绝,以为每分钟最多100稳了。可一次流量高峰系统还是被打出问题,查监控发现诡异现象:某时间点附近一小段时间内接口竟处理了近200次,远超每分钟100。对着限流代码反复看计数器没错阈值也是100怎么放进200个?排查大半天才理解固定窗口限流隐蔽的临界问题(边界突刺):在两个窗口交界处可放进近2倍请求——某分钟后30秒来…- 0
- 0
-
慢下游拖垮核心下单:服务雪崩与熔断避坑复盘
一次让我刻骨铭心的雪崩。我们的核心下单服务会调用一个非核心下游——推荐服务,在下单页给用户推荐几个商品,这功能挂了也不影响下单顶多少几个推荐位无足轻重。可某天推荐服务因自身问题变得极慢,响应从几十毫秒涨到十几秒,然后匪夷所思的事发生了:我那本该坚如磐石的核心下单服务竟跟着一起瘫痪——下单大面积超时失败整条业务线告急。一个无足轻重的推荐变慢怎么会把核心下单拖死?顺调用链复盘才看清传导路径:下单服务用…- 0
- 0
-
放量就 429 账单还暴涨:大模型 API 生产化避坑
我们给一个功能接入大模型 API:用户提交内容后端实时调 LLM 分析返回结果,灰度时一切美好响应又快又准。可一旦放量真实流量涌进来两件事同时炸了:一是接口大面积失败、日志铺天盖地 429 Too Many Requests 被服务商限流了,二是月中财务找上门说这功能的 API 费用几天就烧掉一大笔预算照势头月底要爆表。一边大量请求失败一边花钱如流水,我被这又贵又不稳的双重暴击逼着重新审视调用姿势…- 0
- 0
-
从粗放跨网络调用天真当成调一下拿到结果不设超时无脑重试没熔断不限流不隔离 + 不设超时或设几十秒慢下游把调用线程一个个挂死耗尽线程池调用方自己也垮再沿调用链层层传导冲垮整个核心链路雪崩 + 失败就立即原地无脑固定次数猛重试给过载下游火上浇油 N 客户端乘 M 重试瞬间放大数倍把下游彻底打死死亡螺旋还对扣款下单非幂等操作重试导致重复扣款下单 + 下游已经挂了还一根筋拼命猛打无效请求堆积线程全卡在死路上白耗资源还堵死下游恢复 + 对入口流量来者不拒突发洪峰直接把服务自身资源榨干压垮容量内请求也一起玉石俱焚 + 所有下游调用共用一个线程池连接池一个无关紧要的边缘慢下游就把公共池占满连核心订单支付调用也申请不到线程全线瘫痪 + 下游一挂调用方直接把故障原样上抛一个推荐挂掉整个详情页打不开用户连看商品下单都做不了被次要功能绑架核心 + 客户端无脑轮询所有后端不感知健康把请求往挂掉卡死的实例上送间歇性报错忙的更忙 + 网络调用是黑盒出事只能逐个翻日志加 tcpdump 抓包连蒙带猜耗时数小时抓不到是哪一跳慢 → 2026 现代服务间通信韧性工程 每个调用设合理超时加全链路 deadline 剩余预算传播 + 指数退避加抖动加只重试幂等加重试预算绝不放大故障 + 熔断器失败率超阈值快速失败给下游喘息给自己止血加半开试探 + 令牌桶漏桶限流超容量快速拒绝保住核心容量 + 舱壁隔离每个下游独立线程池连接池故障关在单个舱室 + 降级 fallback 下游不可用返回兜底数据保住主流程 + 健康检查加 P2C 最少连接加异常实例自动摘除 + 每跳成功率延迟熔断状态指标加分布式链路追踪 TraceID 串起整条链路 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
9 人的服务治理与中间件团队 87 天把一套由上百个微服务彼此通过网络调用编织而成、五年里服务从十几个长到上百个调用关系织成一张谁也理不清的大网、却一直停留在调用一下拿到结果天真阶段不设超时无脑重试没熔断不限流不隔离的庞大系统——绝大多数地方调用下游压根不设超时或随手填个几十秒形同虚设慢下游一卡调用线程就永久阻塞傻等高并发下线程池被一个个挂死耗尽调用方自己也垮再沿调用链反向层层传导像多米诺骨牌把整…- 0
- 0
-
微服务架构在第三方接口故障时 35 分钟全平台雪崩的复盘:熔断 + 限流 + 降级三件套落地全过程
一次第三方银行接口 100% 超时,通过 pay-gw 把雪崩传染到全部 50+ 微服务,业务全平台不可用 35 分钟。事故后用 7 天引入 Resilience4j + Polly + bulkhead 三件套,3 个月内类似事故 3 次全部局部隔离。复盘三件套的具体参数 + 协同决策树 + 容错反模式 + 可观测性配置 + 8 条容错纪律,适合所有微服务团队抄作业。- 0
- 0
-
大模型 API 并发完全指南:从一次"开 100 个线程狂调 API、结果全被 429 打回"看懂限流应对
2024 年我做一个批量处理功能要给几万条数据每一条都调一次大模型 API 去做分析。第一版我做得很省事既然要快那就开一个线程池放 100 个 worker 一起往外发请求。本地我拿几十条数据测了测真快几十条几秒钟就跑完了。我心里很踏实调大模型 API 要快嘛就是多开几个线程一起猛发发得越猛越快。可等它真正上线去跑那几万条真实数据一串问题冒了出来。第一种最先把我打懵跑了没几分钟日志里开始刷屏 42…- 0
- 0
-
限流算法完全指南:从一次"固定窗口在临界点放进双倍流量、服务被打挂"看懂四种限流
2023 年我做一个对外开放的 API 服务。为了不被人滥用产品要求给每个用户限流每分钟最多 100 次请求超了就拒绝。第一版我做得很直接用一个计数器记下这一分钟这个用户调了多少次到 100 就拒绝等下一分钟计数器清零重新开始数。本地一测很完美一分钟内连发 100 次正常第 101 次准确地被拒掉。我心里很踏实限流不就是数个数嘛。可上线之后服务还是三番五次地被某些用户打到过载监控上的请求曲线时不时…- 0
- 0
-
接口限流完全指南:从一次"活动一开服务就被瞬时流量冲垮"看懂限流算法
2021 年我维护一个电商下单服务,平时流量平稳,我从没为它能扛多少操过心。直到运营搞了一场大促,海报一推送出去,大量用户在同一分钟涌进来抢购,我盯着监控看着请求量像火箭一样窜起来,然后服务就崩了。不是变慢是直接崩:接口大面积超时,数据库连接被瞬间占满,实例被一个个判定不健康踢出负载均衡,被踢掉的实例那份流量又分摊到剩下的实例上,一场标准的雪崩。我第一反应是加机器,可扩容要时间等新实例起来高峰早过…- 0
- 0
-
限流算法完全指南:从一次"促销把数据库打挂"看懂固定窗口、滑动窗口、令牌桶
2022 年我负责一个商品详情接口,平时扛得很轻松。直到一次运营促销,流量几十倍涌入,响应时间从几十毫秒飙到几秒,大面积超时,整个服务雪崩——不只是这个接口,同服务里别的功能全挂了。问题不是流量本身,是我的服务对"一瞬间涌进多少请求"毫无防备。我加了个固定窗口计数器每秒限 1000,本地完美,下一次促销系统还是被打出问题。我一直以为限流就是数个数够了就拒绝,真相是限流是一整套关…- 0
- 0
-
一波流量把服务冲垮:一次接口限流改造的复盘
对外接口被一波突发流量冲垮,明明"有限流"却没拦住——固定窗口在窗口切换的临界点放进了 2 倍阈值的流量。几天重做限流体系:固定窗口临界缺陷、滑动窗口、漏桶与令牌桶、单机与分布式限流、Sentinel 调用方隔离与熔断降级。- 0
- 0
-
秒杀被黑产刷崩了下单:Sentinel 限流、熔断、热点防护实战
限时秒杀开始三分钟下单服务就挂了,黑产脚本把 QPS 刷到 21 万。一周接入 Sentinel 流量治理:QPS 流控(直接拒绝/Warm Up/排队)、关联与链路限流、慢调用比例熔断降级、热点参数限流精准防刷、系统自适应保护 + 网关流控。后面几场秒杀零宕机。- 5
- 0
-
大促网关 50w QPS 雪崩复盘:多维度限流 + Sentinel 系统保护实战
大促 50w QPS 限流失效雪崩复盘:Redis INCR 单点 CPU 100%。本文讲透 4 种限流算法对比 + 滑动窗口 Lua + 令牌桶 Redis 实现 + Spring Cloud Gateway 多维度叠加(IP/用户/API)+ Sentinel 热点参数 + 慢调用降级,附完整代码 + 压测数据。- 0
- 0
-
限流熔断降级完全指南:Sentinel 与 Resilience4j 的高可用三件套
"流量突然涨 10 倍,系统怎么活下去?" —— 这是每个互联网工程师都会碰到的问题。限流、熔断、降级是高可用三件套,它们不是"可选优化",而是任何对外服务的必备保险。这篇文章把令牌桶、漏桶、滑动窗口讲透,然后讲熔断器模式、降级策略,以及 Sentinel / Resilience4j 等主流框架的工程实践。 问题:没有保护的系统怎么死 真实事故场景: 某接…- 0
- 0
限流
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×