扣费重试一次就多扣一笔，凭据编号得跟着请求走

我爱LV游 · 发表于 2026-11-08 01:06:57

扣费那一步超时，调用方按老规矩重试了一次，结果同一笔被收了两回。用户来问，两边日志各说各的，一边记着重试，一边记着两笔成功，谁也拼不出到底该收几回。

一、每笔请求带一个号

发起扣费时先生成一个号，后续重试都带着同一个号。服务端按号认，认出来就返回上一回的结果，不再真的扣第二次。补办动作过一道确认，要求经办人附上刚查过的当前状态，隔夜再动手的话，中间或许已有别的流程把同一笔结掉了。

号要在重试之前生成并留住，别在重试里临时造。每试一次换一个号，服务端看着就是三笔不同的请求，幂等也就无从谈起。每日收尾安排一轮笔数比对，做成值班的固定动作，差一笔当日就有人接手，拖到对方找上门，说明和补办都得从头来。复盘会上把常问的问题归成几堆，往往就那三五个，写成短说明挂在页面边上，比一份长长的帮助文档有人看。

二、结果按号只记一次

扣费结果以号为主键落一条，重复到达时读到已有那条就返回。靠时间加金额去猜是不是同一笔，碰上用户连着买了两样一样价钱的，很容易并成一笔。季度盘点数一数几种失败状态还分没分开，一律叫失败的话，调用方一概重试，就会踩到本来该等人看的那类。

落库和返回之间断了也要能接上，重启后按号查还查得到。号只放在内存里，进程一退就全忘，重试进来又是一笔新的。状态不明的那几笔单独排给一个人跟进，并进常规量里报数时看不出异常，日子一长就攒成一串谁都接不上话的旧账。

三、超时先查再重试

超时不等于没扣成，可能只是回包丢了。重试之前先按号查一次状态，查到已成直接收尾，别急着再发一遍。和对账那头约好补扣走单独通道并带缘由，混在原来的重试里，日后分不出哪些是补的，对账又得多绕一圈。

查也查不明白的时候，把这笔标成待确认，交给夜里的核对去定。弄不好就是又扣一回，硬着头皮重试的风险全压在这一步。值班交接时把待确认的单子单独列给下一班，注明卡在查不到状态，接手的人先处理这几条，不用等客服转过来才知道。

四、失败要有明确状态

余额不足、通道不通、待确认，几种结果分开记，别一律叫失败。都叫失败，调用方不知道哪些能重试、哪些得等人看，一概重试就会踩到不该重试的那类。版式调整之后留一次说明的复核，由熟悉新口径的人通读一遍，旧答案挂在页面上不动，比缺一条解释更容易把人带偏。

状态连同时刻留给查询接口，客服被问到时能一眼说清卡在哪一步。只给一句未成功，来回追问都得靠猜。复盘会上把重复扣的那几回按触发原因归堆，是号在重试里重造了，还是回包丢了没先查，两种改法隔着一层。

五、补扣走单独通道

确实该收却没收成的，走单独的补扣流程，带上原笔号和缘由。别在原来的重试里顺手补，补的那笔和正常扣的混在一起，日后对账分不出哪些是补的。预算里给明细页的查询留一份，用户能自己点进去核，来问的量掉下来，客服那头省下的来回比这点投入多。

补扣之前再核一次用户当前的状态，那笔可能已经被别的路收了。隔了一天才补，中间发生的事不少，凭旧记录直接下手容易多收。新人上手先给他一笔超时重试的例子，让他按号查一遍状态再决定发不发，跑过一次就明白超时不等于没扣成。

六、夜里跑一遍核对

每天把业务侧该收的笔数和账务侧实收的笔数对一遍，按号逐条比。多一笔少一笔当天就冒出来，比等用户发现再查从容得多。值班交接时把当天问得多的那几类报给下一班，接手的人一看就知道该先补哪条说明，不用等工单攒成堆。

核对结果按状态归类，待确认那几笔单列，第二天优先处理。混在正常笔数里，它们会一直挂着，挂到月底成了一串说不清的尾巴。给答问的同事备一张按笔号查状态的视图，把所处环节和时点摆齐，只有一句笼统回话的话，来问的人还得再跑一趟。

重试这件事，难的不是多发一次请求，是让重复到达的请求不产生第二笔账。带号、按号记、先查、明状态、单补、夜核，六件接着才稳；缺一件，网络一抖就得多退一笔。

棋子721 · 发表于 2026-11-08 01:09:52

看完感觉打开了新思路，以后遇到类似情况知道该怎么处理了。

manyao · 发表于 2026-11-08 03:17:12

楼主的经历很有参考价值，给了我很多新的思考方向，非常感谢。

		自动登录	找回密码
密码			加入W10