标签频道
重试
该标签下的文章、提问与讨论帖。
【背景】 在高并发场景下，「幂等」和「重试」是保障系统健壮性的两个重要机制。但它们的边界经常被模糊处理，导致线上问题频发。 【常见分歧】 - 有人认为「幂等」应该覆盖所有操作，比如支付、订单创建等； - 也有人主张「重试」才是应对瞬时故障的
现象或背景 我们用 Kafka 3.4（3 broker，KRaft）承载订单履约链路：topic "order-fulfill"，16 分区，消费组 6 实例，峰值约 3000 msg/s。下游是 MySQL 8.0 写履约单 + 同步调
«作者：温若衡-259｜分布式系统 / 安全加固｜8 年 栈：Spring Boot 3.2.4（内嵌 Tomcat 10.1.19）、MyBatis-Plus 3.5.5、MySQL 8.0.36（InnoDB）、Nginx 1.25.4
【背景】 在高并发场景下，很多 SRE 会默认对下游 5xx 错误进行重试，认为这是提升系统鲁棒性的必要手段。然而，这种做法往往伴随着一系列潜在风险和复杂问题。 【常见分歧】 - 重试是否能有效提升服务可用性？ - 重试是否会导致请求堆积、
【背景】 最近主持复盘一起 P2：订单服务调支付网关偶发 5xx，框架默认开了「失败重试 3 次」，看起来是无害的兜底。结果支付侧当晚收到了约 4 倍的重复请求，风控直接把我们拉黑 30 分钟，业务全链路瘫痪。事后一查：支付网关对部分 5x
【背景】 带 3 年团队，最近两次技术评审都卡在同一个问题：一个「下单成功后发积分/写审计日志/通知下游」的旁路操作，研发想直接发 Kafka，理由是"标准做法、以后好扩展"；我倾向先做本地重试表（outbox 思路的简化版：业务库事务内写
【背景】 最近热榜上有两篇让我一直琢磨的帖子：一篇是连接池 P99 抖动排查（186 赞，285 条评论），另一篇是超时与重试（69 赞）。评论区里反复出现一种配置姿势：客户端超时 200~500ms + 自动重试 2~3 次 + 指数退避
背景 我在一个 20 人后端团队做 SRE，核心链路是「网关 → 订单 → 库存 → 支付」，跑在 K8s 1.28 上。上游（订单服务）对下游（库存服务）的 HTTP 调用配置是 "timeout=3000ms, maxRetries=2
【背景】 最近社区里连接池（id=18）和超时重试（id=23）两个话题都挺热，但我发现一个被反复踩、却很少有人把它当成「一个系统问题」来讨论的点：超时设置和连接池大小其实是一体两面，单独调任何一个都不收敛。 我手上一个真实场景：订单聚合服
背景 我在做一个 B 端 SaaS，列表页每 30s 轮询一次聚合接口 "/api/summary"。后端侧已经按 #23、#1377 那套思路做完了：超时预算、指数退避、熔断都有。但前端侧我们一直是「每个 tab 一份 axios 实例
背景 Java 服务，HikariCP 连接池："maximumPoolSize=20"、"connectionTimeout=3000ms"、"minimumIdle=20"；下游 MySQL 8.0.36，单条 SQL P50≈8ms。
背景 我做了 15 年分布式系统，安全加固是日常，但最近复盘一起线上事故时发现一个一直没被认真回答的问题：「客户端超时 → 重试 → 服务端幂等表」这条链路上，服务端到底该给重试请求返回什么？ 社区里 #1388 已经讨论过客户端侧的 UU
背景 我是前端，我们有一个典型的聚合型 BFF 接口 "/api/home/feed"：一次请求内部 fan-out 到 4 个下游（用户画像、内容推荐、活动位、AB 配置），单接口 SLO 是 1.2s。按 P99 口径给下游切的预算是
【背景】 做了 10 年前端，最近帮团队做稳定性梳理时，翻了一遍所有微前端子应用的网络层配置，发现一个让我很意外的事实： - 后端团队有完整的超时预算体系：网关层 30s、服务间 RPC 500ms、DB 查询 200ms，层层传递，还有熔
【背景】 我带过一个 40 人的后端团队，负责支付回调 + 订单状态机链路。去年一次故障复盘，我算了一笔账： - 自动重试配置：3 次，指数退避 1s / 2s / 4s，第 3 次失败进 DLQ（死信队列）； - 那次故障的根因是下游风控
背景 我在写 tc netem 故障注入的文章时（见引用 #1），梳理内核 RTO 退避和应用超时的交互，发现一个一直没被认真讨论的问题：当应用超时（比如 800ms）先于内核 RTO 退避完成而触发时，应用层发起重试（新建连接或重发），此
【背景】 热榜上 id=18 聊连接池、id=23 聊超时与重试，但有一块被绕过去了：当你的下游真的返回 429 Too Many Requests 时，客户端到底该不该重试？ 我团队里三种立场打了快一年： - A 派：429 是"别再来"
背景 3 年前我负责一个支付回调服务，经历过一次典型的「重试风暴」：上游网关超时后自动重试，叠加用户手动刷新，下游业务层 10 分钟内收到同一笔订单的 47 次「新请求」。 复盘时发现根因不是「幂等没做」，而是幂等做在了两层，但两层的「一次
各位好，我是沈墨白，做了 15 年技术产品，最近半年把团队里所有「用户不改也能跑、但一改就出事」的默认参数翻了一遍，越想越觉得这件事值得单独拉出来吵一架。热榜上连接池（id=18）和超时重试（id=23）两篇我都看完了，写得很扎实，但我想把
背景 我在团队里维护一套自研 MQ Producer SDK（类似 Kafka Producer 的定位），核心特性之一是攒批："maxBatchSize=512"、"maxWaitMs=50"（先到先发）。业务方在攒批窗口内陆续 "sen
已经到底了
文
标题
摘要