限流

背景 我负责一个聚合网关（Java 17，Netty + Reactor），核心是把多个下游（订单、库存、风控）的结果并发扇出后再聚合返回。整体 QPS 约 3000，单个下游 RT 正常 20~60ms，但风控下游 P99 会周期性飙到

【背景】 订单聚合服务，JDK 21 虚拟线程（每请求一个 vThread），一次请求需扇出 6 个 gRPC 下游（库存/价格/物流/风控/营销/会员），单下游超时 200ms，整体 deadline 800ms。 上游 Nginx 压测

【背景】我负责一条 B 端 SaaS 的接口自动化（Python 3.11 + pytest 7 + httpx，约 500 条用例），后端 Spring Boot 3，网关层挂了 Sentinel 限流 + 熔断。用例是「造数 → 调接口

背景 上周在排查一次 P99 毛刺时，顺带翻了下我们网关侧的几段老代码，发现一个挺有意思的分歧：同一个团队里，三个不同服务的"安全门"（鉴权、风控、限流、白名单校验）在下游依赖抖动时，处理方式完全不一样——有的直接 403 拒掉，有的直接放

【背景】 最近翻了社区几篇帖子——连接池调参、超时重试、线程池从 200 拉到 2000 雪崩的复盘——发现大家聊的都是「单点怎么调」，但有个更上游的问题很少被正面讨论：当系统整体过载（不是某个组件慢，而是入口流量超过承载力），你的第一反应

«结论先行：几乎所有基于"滑动窗口 / 令牌桶"的单机限流器，都默认时间源是平滑的；一旦 NTP 用 step 模式把本机时钟往前跳 300ms+，限流器会在同一瞬间把整个窗口的配额一次性烧完，表现就是"没有任何改动、突然一片 429"。这

一、现象：周五续期窗口，3 个域名里 1 个续不上，差点裸奔 上个月（2024-05）我们负责一批对外 HTTPS 域名，全部走 Let's Encrypt + certbot（版本 1.30.0）自动续期，由 systemd 的 "cer

背景 热榜上已有两篇好帖把「限流卡什么指标」（QPS vs 并发数）和「限流放哪一层」（Sidecar vs SDK）讲得很清楚了。但实际落地时，我卡在下一步：阈值那个数字，到底怎么来的？ 上个月帮一个团队做容量评审，网关上某个核心接口限流

背景 上个月帮一个团队做容量评审，他们网关层给一个订单查询接口配了 QPS 限流 5000，压测跑下来 QPS 4800、P99 稳定 45ms，一切"正常"。结果上线第三天，下游 MySQL 主从切换，P99 飙到 2.3s，QPS 只跌

结论先行 超时和重试不是「加个配置就完事」的运维项，而是容量规划的一部分。我见过三次线上事故，根因都不是 bug，而是超时和重试配错了： 1. 上游 200ms 超时，下游 P99 是 180ms —— 平时没事，下游一次 GC 抖到 30