这是一个创建于 936 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景：单体项目。比如我在微信支付上成功支付了一笔金额，但是在支付回调的时候，由于某些原因我的事务处理失败了，导致后面的业务逻辑处理失败，请问有什么思路去处理呢？
疑问：回滚事务就需要申请退款，这个思路明显不行。但是怎么重新发起我的业务逻辑处理呢？
感谢大佬提点。
 |
1
julyclyde 2022-05-30 10:39:25 +08:00  1
放个消息队列来管理重试
|
 |
2
execute 2022-05-30 10:50:58 +08:00 1
我记得微信支付回调的时候，你给它返回失败，它就会一直重试的呀，直到你给它返回成功。
|
 |
3
JackMi 2022-05-30 10:53:49 +08:00 1
1 楼说的跟我们公司做的差不多，我们第一次失败后加入队列进行重试，重试失败后就主动通知管理员，并给用户进行退款操作。体验比较好些。
|
 |
4
yurong333333 OP @execute 是的，如果在回调接口返回失败给微信，微信会一直尝试回调，时间间隔会变得越来越产。但是回调里面就是我们的业务逻辑处理，所以处理失败需要重新发起。
|
|
5
yurong333333 OP |
 |
6
akiraX 2022-05-30 11:01:22 +08:00
微信回调在未收到成功确认之前会重复发送回调通知，在你的事务处理未成功之前不要给微信返回成功。
|
|
7
julyclyde 2022-05-30 11:03:14 +08:00
@yurong333333 你可以在第一步“接收微信支付回调”这里就录入消息队列，然后就给微信支付返回成功就好了
把接收回调和实际处理也断成两段来做 |
|
8
akiraX 2022-05-30 11:03:39 +08:00 1
也可以收到微信回调通知后，保存这次通知消息后立即给微信返回成功，再异步来处理这个回调消息
|
|
9
yurong333333 OP @akiraX 感谢。
|
 |
10
sujin190 2022-05-30 11:18:31 +08:00 1
最好分成两步，第一步支付状态更新和业务逻辑处理，支付状态更新成功之后就给微信回成功，之后业务逻辑更新放入消息队列异步完成，收银台支付状态更新毕竟简单，事务绑定更新失败概率极低而且一旦上线更新频率也非常小，业务逻辑大多毕竟复杂，修改频率也会高很多，分开之后至少保证钱肯定是对的，业务逻辑异常修复和补偿都相对还是容易做的，最不济还可以搞个定时任务提取支付流水和业务状态逻辑比对然后再补偿修复就是了
|
 |
11
libook 2022-05-30 11:24:37 +08:00
搞个消息队列，接到微信的回调，就查一下本地服务是否有成功处理这个订单的记录，有的话就返回成功，没有的话就存下这条消息，并返回失败。服务消费消息，成功处理完一个订单就存一个这个订单的成功记录。
这样，假设服务正常的话，每个订单微信会回调两次，第一次失败，第二次成功。 |
 |
12
Jooooooooo 2022-05-30 11:34:48 +08:00
扣款相关动作都是最终一致的.
发消息去补偿. |
|
13
sujin190 2022-05-30 11:37:44 +08:00
而且吧，公司内部几乎财务的要求是很高的，自己的支付流水、微信给的支付流水和银行账户收到的钱差个几分估计你都得找出来问题在哪，虽然订单的要求也很高，要是异常也很要命但是大多还是有处理商量的余地的，支付流程核对这种要是量稍微高一点，结果出来差一点点又不多不少核对起来真是可以要了老命啊，组织架构中支付流程一般是财务负责，而订单则大多有运营、客服或者物流负责处理，要求周期确实不一样
|
 |
14
zhuyao 2022-05-30 11:54:16 +08:00 1
回调里支付成功的消息直接入到中间表然后返回 success 然后用定时器跑中间表的数据到业务表中，或者像楼上说的用消息队队列
|
 |
15
oneisall8955 2022-05-30 11:59:21 +08:00 via Android 1
公司的做法比较粗暴，插入失败记录，job 补偿，补偿的操作必须是幂等
|
 |
17
jucelin 2022-05-30 14:27:19 +08:00
job 主动查询订单支付状态
对于有支付订单，但 x 分钟内无支付结果的订单，主动调接口查询 |
Select Language