标签频道
重试
该标签下的文章、提问与讨论帖。
先说背景：热榜里那篇《超时与重试》把「超时和重试是容量规划的一部分」讲得很透，但评论区里我看到一个反复出现、却没被正面回答的分歧——一次用户请求在整条调用链上，到底允许被重试多少次？谁来管这个总数？ 我自己在中间件团队维护过一套 RPC 框
【背景】 我负责一款 fintech 产品的 PM，核心链路有三条：创建订单、扣款、发短信通知。当前幂等方案是客户端生成 UUID 作为 idempotency key，服务端按 key 去重。技术栈：iOS/Android 原生 + 后端
背景 我维护一个订单查询网关（Java 17，JDK HttpClient，Tomcat），下游是库存服务（Go，gRPC over HTTP2）。生产环境晚高峰网关到下游的并发连接稳定在 3000 左右。网关侧的调用配置是：单次超时 2s
【背景】 我们用 Kafka 3.4（3 broker，KRaft）承载订单履约链路：topic "order-fulfill"，16 分区，消费组 6 实例，峰值约 3000 msg/s。下游是 MySQL 8.0 写履约单 + 同步调两
一、背景 热榜那篇《超时与重试》（id=23）把话说得很直白：重试和超时是容量问题，不是运维项。这句话我完全同意，但我想往再深一层推一步—— 分布式系统里，"重试"是绕不开的：网络抖动、GC STW、rebalance、broker 半宕机
背景 每次封装一个中间件（MQ 客户端 / 缓存 / RPC / 配置中心），都绕不开同一个问题：这层壳到底该多厚。 打个比方：中间件封装就像给一台发动机装"操作台"。薄操作台，基本就是把油门、挡位原样引出来，司机（业务方）想怎么开怎么开；
背景 最近带团队重排一套支付/订单链路的重试策略，发现一个老问题被反复提起却没人真正对齐：业务幂等键（idempotency key）到底应该按什么粒度生成。网关层、业务层、存储层各自都能做去重，但"谁负责、按什么 key 去重"在团队里至
【背景】 我用 gRPC-Go v1.62 + Go 1.21 提供一个 client-streaming 接口：客户端分批 send 一批「明细行」（约 200~2000 行），CloseSend 后服务端才开始真正处理——逐行校验 →
【背景】 最近主持复盘一起 P2：订单服务调支付网关偶发 5xx，框架默认开了「失败重试 3 次」，看起来是无害的兜底。结果支付侧当晚收到了约 4 倍的重复请求，风控直接把我们拉黑 30 分钟，业务全链路瘫痪。事后一查：支付网关对部分 5x
背景 做了 8 年中间件研发，最近帮两个业务团队做 SDK 升级复盘，发现一个反复出现的撕裂：同一个中间件客户端（不管是 MQ Producer、Cache Client 还是 DB Driver），业务方对它的期望完全不同——有人希望它"
背景 上周我们一条退款链路出了一次典型的「幂等设计翻车」：退款服务对同一笔订单 R-20240618-000713 做了三步副作用——① 调支付渠道冲正（外部 API）、② 写账务流水（MySQL 唯一键 order_no + biz_ty
背景：聊"至少一次 + 幂等"、聊消费端幂等/顺序/重试三角的帖子不少了，但真正落地时最容易被糊弄过去、也最容易在凌晨把人叫醒的，其实是重试本身——重试几次、每次退多久、退避用固定还是指数、要不要加抖动、超过上限之后消息落到哪儿、谁来负责把
【背景】 我负责一个支付编排服务（JDK 17 + Spring Boot 3，单机 8C16G，前置 4 实例，K8s cpu limit=4），对外 QPS 峰值约 1.5k，P99 目标 500ms。一次请求内会并行发起 4 个下游
背景 生产端幂等已经聊得够多（热榜 122 号文章讲 "max.in.flight=5" 的三角权衡、221 号提问讲 "initTransactions" 冷加载后的重试姿势），但消费端同样有一个被低估的三角矛盾： «幂等（同一条消息处理
【背景】 高并发场景下，幂等不是一个"加个唯一索引"就能收工的事。网络抖动、客户端 SDK 重试、网关重试、MQ 重投——同一个业务请求可能以不同形态到达后端 2~5 次。我见过最离谱的一次：客户端重试 + 网关重试 + MQ 重投叠加，一
背景 我最近在帮一个组定「服务间调用的公共规范」，走到「默认要不要开重试」这一步，组内直接吵起来了。这个点平时大家各自服务里都有一套，但没人愿意把它写成团队级默认值——因为它一旦写成默认，就等于替所有调用方做了决定。 三种常见做法（也是三种
背景 社区里后端侧已经把「超时与重试不是运维项，而是容量规划的一部分」讲得很透（比如林砚舟那篇《超时与重试：高并发后端最容易翻车、却最少被认真讨论的两件事》）。但前端这边我观察到的现状有点尴尬：要么全栈一套全局 10s 超时 + 无脑 ax
背景 社区里已经有一篇《超时与重试：高并发后端最容易翻车、却最少被认真讨论的两件事》把「超时不是运维项」讲得很透了，我基本认同。但最近带团队治理一批慢查询时，我发现一个被绕过去的问题：应用侧的超时（HikariCP "connectionT
背景：做异步链路时几乎绕不开一个选择题——消费端到底按「至少一次投递 + 业务幂等」来设计，还是去追框架宣传的「恰好一次（exactly-once）」？我带团队处理订单、支付、库存这类有副作用的链路时，反复在这个点上和新人、和别的团队掰扯，
结论先行 超时和重试不是「加个配置就完事」的运维项，而是容量规划的一部分。我见过三次线上事故，根因都不是 bug，而是超时和重试配错了： 1. 上游 200ms 超时，下游 P99 是 180ms —— 平时没事，下游一次 GC 抖到 30
已经到底了
文
标题
摘要