-
我的下单接口偶尔会给同一个用户重复下两笔一模一样的单、甚至重复扣款,可我代码里明明每次只下一单,排查半天才明白是客户端超时重试、用户手抖多点了几下,让同一个请求被发了好几次、而我的接口压根没防着重复的深度复盘
我有个下单接口:接到请求就创建订单、扣一次款,逻辑清清楚楚一次请求一个订单。我自己测试点一下下一单完美无缺。可上线后客服陆续投诉:有用户只下了一单,系统却给他创建了两三笔一模一样的订单、重复扣了好几次款。我翻日志发现重复订单都来自短时间内几乎同时到达、内容完全相同的多个请求。我以为是并发 bug、循环写错,检查下单逻辑都没问题。顺着重复请求往上游追才恍然:问题不在接口处理一次请求的逻辑,而在同一个…- 0
- 0
-
偶发 502 故障复盘:keep-alive 超时不匹配、缺超时、重试风暴与连接池治理
一套日常 QPS 三四千的微服务系统,网关到订单服务这一跳每隔一阵就冒出大约千分之三的 502,监控曲线上是几个对不上流量高峰也对不上发布的孤立尖刺,客户投诉「点一次失败再点一次就好」,而后端订单服务的业务日志却干干净净——请求根本没进到业务逻辑,就在网络层被掐断了。这篇把这次「查无此错」的偶发故障从头复盘:一开始误判为上游 OOM 重启、白白扩容浪费了四十分钟,直到用 ss 看连接状态、tcpd…- 0
- 0
-
gRPC 微服务超时与重试工程化完全指南:从一次"下游慢 800ms 上游 5 个服务全部雪崩"看懂为什么加 timeout 远远不够
2023 年我们公司有一套基于 gRPC 的微服务架构十几个服务互相调用拓扑大概有三四层深接手时表面看挺平静 QPS 不算高响应时间也还行可三个月里我们陆陆续续出了几次让我刻骨铭心的故障第一次是周五晚上一个下游的搜索服务因为索引重建延迟变高从 50ms 涨到 800ms 结果上游所有依赖它的服务的线程池被打满整个调用链上的 5 个服务全部超时雪崩业务被打挂 30 分钟第二次最莫名其妙某个接口压测时…- 2
- 0
超时重试
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×