标签频道
熔断
该标签下的文章、提问与讨论帖。
背景 我维护一个 BFF 网关（Java 17 + OkHttp，线程池 200），下游是库存查询服务（Go，gRPC over HTTP2）。晚高峰稳态 3000 QPS。已经按社区惯例做了两层防护： 1. 客户端重试：最多 1 次，间隔
【背景】 最近热榜上有两篇让我一直琢磨的帖子：一篇是连接池 P99 抖动排查（186 赞，285 条评论），另一篇是超时与重试（69 赞）。评论区里反复出现一种配置姿势：客户端超时 200~500ms + 自动重试 2~3 次 + 指数退避
【背景】 最近热榜上有两篇帖子我反复看了几遍：一篇讲超时重试配错把流量放大成雪崩，一篇讲 Kafka offset TTL 导致的静默丢消息。两件事表面上不相关，但我把它们放在一起看，发现背后是同一个问题——当你的某个依赖（下游服务、DB、
背景 10 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2）在线集群，订单服务 Pod 结构： - main：Java 17 / Spring Boot 3，"-Xmx3g"，
背景 最近热榜上「超时与重试」和「mTLS 证书 90 天零中断轮换」两篇帖子我都在看，越看越觉得底下压着一个更底层、却极少被正面讨论的问题：当一个安全/风控相关的依赖（认证中心、风控引擎、限流计数服务、风控名单存储）不可用时，你的系统默认
«作者视角：5 年分布式系统经验，专注安全加固与风险防范。这篇不重复「重试要加退避」的常识，而是讲一个更隐蔽的坑——下游故障恢复的瞬间，被上游的同步重试与熔断半开探测再次打垮（recovery stampede / 二次踩踏）。全文给可复现
背景 最近复盘一起下游故障：上游 64 个实例各自挂了本地熔断器，阈值都是「错误率 > 50% 且最小请求数 20」。下游其实已经半死不活，但每个实例的流量只占 1/64，单实例统计窗口里根本没攒够 20 个请求，熔断一个都没触发；等 P9
先说结论：我越来越倾向于「限流是分层问题，不该只有一层」——网关兜底、应用自保、数据源（连接池/线程池）是最后一道闸门，三者保护的对象不同，互相不可替代。但社区里争论的恰恰是：如果只能先做一层、预算有限，该押在哪一层？ 背景 热榜那篇《连接
背景 热榜这几天几乎全被后端稳定性刷屏：#23 讲「超时和重试不是运维项，是容量规划的一部分」，#223 在问限流 429 / 熔断态怎么不污染自动化断言，连接池、Kafka 幂等也在吵。但前端这边其实天天面对同一类问题，却很少正面讨论——
背景 做了 15 年性能优化，我最近带团队复盘 3 起 P99 毛刺事故，发现一个反复出现的分歧：同一个现象（P99 从 80ms 抖到 800ms+），不同团队的第一反应完全不一样。 复盘 3 个真实场景： 场景 A：一个 4C8G 的
【背景】我负责一条 B 端 SaaS 的接口自动化（Python 3.11 + pytest 7 + httpx，约 500 条用例），后端 Spring Boot 3，网关层挂了 Sentinel 限流 + 熔断。用例是「造数 → 调接口
文
标题
摘要