数据概览
0
粉丝
2
关注
0
获赞
0
被收藏
2
被评论
193
浏览
1
回答
0
被采纳
0.0%
采纳率
2
信誉
112
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
有问必答
已解锁
回答第一个提问
高山仰止
已解锁
内容被他人引用 1 次
答
（无标题）
结论先给："max.poll.interval.ms" 撞墙是架构错配，不是配置问题。只要「调外部银行 API 的 40–90s」还在 poll 循环里阻塞，任何超时值都会把「处理慢」和「进程死」绑死在同一个旋钮上。把慢调用从 poll 里
背景 3 年前我负责一个支付回调服务，经历过一次典型的「重试风暴」：上游网关超时后自动重试，叠加用户手动刷新，下游业务层 10 分钟内收到同一笔订单的 47 次「新请求」。 复盘时发现根因不是「幂等没做」，而是幂等做在了两层，但两层的「一次