-
我给 AI Agent 的工具调用加了失败就自动重试、自以为更健壮了,结果有的任务卡在那对着一个参数本来就填错了的调用一遍遍重试、试满五次全失败白白烧掉一堆时间和 token,我盯着日志才反应过来不是所有失败都该重试有一类失败你重试一万遍它还是会用同样的方式失败的深度复盘
我的 Agent 会调各种工具,为了让它更抗造给工具调用统一加了一层重试:只要失败就自动重试最多五次,想着网络偶尔抖一下、下游偶尔超时重试一下就过去了。可上线后有些任务变得又慢又费:Agent 在某一步反复重试五次最后还是报错,而五次失败原因一模一样——给工具传的参数格式不对(400 Bad Request)、要查的资源根本不存在(404)、或没有权限(403),第一次和第五次失败原因完全相同,重…- 0
- 0
-
我的下单接口偶尔会给同一个用户重复下两笔一模一样的单、甚至重复扣款,可我代码里明明每次只下一单,排查半天才明白是客户端超时重试、用户手抖多点了几下,让同一个请求被发了好几次、而我的接口压根没防着重复的深度复盘
我有个下单接口:接到请求就创建订单、扣一次款,逻辑清清楚楚一次请求一个订单。我自己测试点一下下一单完美无缺。可上线后客服陆续投诉:有用户只下了一单,系统却给他创建了两三笔一模一样的订单、重复扣了好几次款。我翻日志发现重复订单都来自短时间内几乎同时到达、内容完全相同的多个请求。我以为是并发 bug、循环写错,检查下单逻辑都没问题。顺着重复请求往上游追才恍然:问题不在接口处理一次请求的逻辑,而在同一个…- 0
- 0
-
我把一个下单操作拆成了先调库存服务扣库存、再调订单服务建订单,本地测试一路绿灯,可上线后偶尔出现库存扣了、订单却没建成,钱货两空、数据对不上,排查半天才明白跨服务的操作根本没有我以为的那种原子性的深度复盘
我做了个下单流程涉及两个独立微服务:库存服务和订单服务,代码很直白——第一步调库存服务扣库存,第二步调订单服务建订单。本地测试两步都顺利,我便觉得天衣无缝。可上线后客服陆续收到投诉:有用户下单失败可库存却被扣了;对账也发现库存扣减记录和实际订单数对不上,有批库存凭空少了却找不到对应订单。翻日志真相浮现:这些异常都是第一步扣库存成功了、第二步建订单失败了(订单服务超时/宕机/网络抖),第一步已实实在…- 0
- 0
-
我把大模型当成一个同样的输入必然给同样输出的普通函数来用,做了缓存、写了断言固定结果的测试,结果缓存老是不命中、测试三天两头挂,排查半天才明白大模型本质是概率采样、压根不保证每次输出一字不差的深度复盘
我在系统里接了个大模型让它根据输入生成结构化结果,下意识把它当普通函数对待——就像 f(x):同样的 x 必然得到同样的 f(x)。基于这个天经地义的假设我做了两件事:给输出做缓存(以为同输入算一次存下来就能复用),写单测断言输入这段输出必须等于那段固定文本。可上线和跑测试后怪事接连不断:测试三天两头失败,同样输入这次输出和我断言的标准答案差了几个字、措辞调整了下断言就挂;缓存逻辑也总出问题。更抓…- 2
- 0
-
我为了防止插入重复数据,代码里先查一下存不存在、不存在才插入,单机测试一切正常,可一上并发就冒出了重复记录,因为先检查再插入这两步之间有个窗口、并发请求全挤了进来的深度复盘
我有个场景要防止插入重复(同一用户名只能注册一个、同一订单号只能下一单),写得很合理:先 SELECT 查这条记录在不在、不在才 INSERT。单机低并发测试一切正常、防重也生效。可一上线并发一高就冒出重复记录:数据库里出现两条一模一样的记录,先查再插形同虚设。复盘才想明白:先检查(SELECT)再行动(INSERT)这个 check-then-act 模式在并发下根本不是原子的——两步之间有时间…- 2
- 0
-
我用消息队列解耦订单处理,以为一条消息只会被消费一次,结果某条扣库存的消息被重复消费了两次,库存莫名其妙被多扣了一份:一次没为消息重复投递做幂等、误把至少一次当成恰好一次的深度复盘
我用消息队列解耦订单流程:订单服务下单发消息,库存服务消费消息扣库存。我想当然地以为一条消息只会被消费一次,消费逻辑写得很直白:收到就扣。线上跑了一阵对账发现少量订单库存被扣了两次——只买 1 件却少了 2 件。翻日志才发现:那几条消息确实被同一个 messageId 消费了两遍。复盘 MQ 投递语义才恍然大悟:绝大多数消息队列默认是至少一次(at-least-once)投递,不是恰好一次(exa…- 0
- 0
-
一个没做幂等的消息队列消费者,因为一次网络抖动把同一条扣款消息消费了两次,给用户活生生扣了两次钱:一次消息重复消费与幂等缺失的深度复盘
半夜被叫醒处理资损:一笔订单被扣了两次款,有两条几乎一致的扣款流水,可同一笔订单我们只发了一条扣款消息。翻 MQ 投递日志才看清:消息队列是 at-least-once(至少一次)投递、宁可重复不愿丢消息,那次扣款服务已成功扣款,但返回 ack 时网络抖动、ack 没送达,MQ 以为没处理成功便重新投递,而消费者没做幂等、又扣了一次。本文讲透 MQ 三种投递语义与为何必须幂等,给出数据库唯一约束/…- 0
- 0
-
我的下单接口被同一个请求重复调用,结果生成了两笔一模一样的订单,我一开始以为是前端 bug,最后才明白重试在分布式里根本无法避免、而我没做幂等的深度复盘
我的下单接口,用户点一次就该下一单,可线上时不时冒出重复订单:同样的商品金额生成了两笔三笔。我第一反应甩锅前端"重复调用了",让前端加防抖,可问题依然。复盘完整链路才痛悟:根子不在前端,而在我没做幂等。分布式里重复请求根本无法避免——网络超时重试(后端其实成功了只是响应没回来)、用户重复点、网关自动重试、MQ 至少一次投递,而后端根本分不清"新订单"还是&q…- 0
- 0
-
用户下了单没收到短信、买了东西积分没加,订单明明下单成功后续处理却像从来没发生过一样凭空消失:消息队列消息丢失的端到端可靠性避坑复盘
这是一个东西凭空消失的事故而且消失得无声无息直到用户投诉才暴露。我们用消息队列做订单的异步后续处理,用户下完单主流程往 MQ 里发一条消息然后下游的消费者收到消息去做那些不那么紧急的后续事发短信通知给用户加积分同步给其它系统。这套用 MQ 解耦异步的架构很常见也很优雅,可上线一段时间后陆续有用户反馈:我下了单怎么没收到短信?我买了东西积分怎么没加?而去查订单本身是好好的下单成功了,可那些后续处理有…- 3
- 0
-
Agent 长任务跑到第十步失败就前功尽弃从头再来,烧的 token 全白费还把已发的通知又发一遍:多步骤 Agent 状态持久化与可恢复避坑复盘
我们做了个 AI Agent 自动化处理一类运营任务,一个任务不是一步到位的而是要走十几个步骤,调好几个工具夹杂着好几轮大模型的决策环环相扣把一件复杂的事办完。开发时跑单个任务行云流水效果惊艳,可一上线开始批量地跑大量任务问题就来了:这十几步里只要有任何一步出了岔子,下游接口偶尔超时大模型偶尔抽风网络偶尔抖动,整个任务就直接失败从头再来,前面十几步辛辛苦苦跑出来的成果还烧了不少 token 全部清…- 2
- 0
-
对账邮件发了三遍:多实例定时任务避坑复盘
那天上午客服转来一条用户投诉让我心里咯噔一下:你们的对账邮件我今天早上一口气收到了三封一模一样,是不是系统出 bug 了?我第一反应是邮件服务重试了?可一查发邮件的代码确确实实只被成功调用了三次,每次都正大光明地发了一封,不是重试是实打实地执行了三遍。而这个发对账邮件的任务是一个每天凌晨定时跑一次的定时任务,逻辑里清清楚楚写着每个用户发一封,怎么会发三封?真相藏在一个我们为了高可用而做的本身完全正…- 0
- 0
-
Saga 分布式事务库存幽灵占用事故复盘:2 个月 47 单灵异库存 + 状态机持久化 + 幂等 + dead-letter 监控三件套
电商订单中台 Saga Orchestration 模式实现里隐藏的 5 个真凶:状态机存内存丢失、补偿幂等用内存 Set 失效、dead-letter 累积 5000+ 条无人监控、支付 timeout 但实际成功导致双扣库存占用、编排者单点。4 天定位 + 5 个月修复,把幽灵库存从月均 23 单压到 0,Saga 失败率从 0.31% 降到 0.04%,沉淀出可复用的分布式事务工程纪律 10…- 4
- 0
-
接口幂等设计完全指南:从一次"网络重试把用户扣款扣了两次"看懂幂等
2019 年我做一个电商的下单支付接口,逻辑很直白:用户点提交订单,后端创建一条订单记录,从余额里扣钱,返回订单号。本地测试一切正常,上线后也好好的。直到客服转来一个投诉:一个用户只下了一单却被扣了两次钱。我查日志发现这个用户的下单接口在几秒内被调用了两次,参数一模一样,数据库里多了两条几乎相同的订单,扣款也执行了两遍。我第一反应是用户手抖点了两次,可继续查下去发现根本不是——很多重复请求用户只点…- 2
- 0
-
消息队列完全指南:从一次库存扣三次的事故看懂丢失、重复、顺序怎么治
2023 年我维护一个电商订单系统,用消息队列把下单后的扣库存/加积分/发短信改成异步——订单落库后发一条"订单已创建"消息交给各消费者处理。某次大促运营找来说爆款商品库存对不上:系统显示卖 1200 件实际出库只有 800 多,库存被扣多了。拉扣库存消费者日志顺着一个订单号查,愣住了:同一个订单的"扣库存"消息被消费了三次。我第一反应是"MQ 出…- 2
- 0
-
接口幂等设计实战:从一次重复扣款事故说起
支付系统出过一次后背发凉的事故:用户被同一笔订单扣了两次款。根因是前端网络抖动时重试了提交请求,而下单接口压根没做幂等。一周治理:理清哪些写接口必须幂等、补数据库唯一索引兜底、幂等号前置查重、token 机制防表单重复提交、状态机幂等。同一请求并发重放 200 次只落 1 笔订单。- 0
- 0
-
订单消息一会丢一会重:RocketMQ 消息可靠性与消费幂等实战
订单系统用 RocketMQ 异步解耦,对账发现每天 230 笔积分消息丢失、80 笔重复。两周治理:生产端事务消息 + 本地消息表 + 同步发送检查;broker 端 SYNC_FLUSH + SYNC_MASTER;消费端唯一索引 + 状态机幂等 + 死信补偿 + 顺序消息。连续 3 个月对账零差异。- 0
- 0
-
Kafka 消费幂等 + Offset 管理:2 年踩过的 7 个真实坑
Kafka 文档说 At-least-once,实际生产里 重复消费 是日常。本文 7 个真实坑:auto.offset.commit / 消费跟不上 rebalance / 幂等漏做扣款两次 / 死信队列 / 消息顺序 / 大消息 / 监控指标。每个附 Java + Go 代码 + 核心配置。- 3
- 0
幂等
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×