共计 680 个字符，预计需要花费 2 分钟才能阅读完成。
业务需要
阐明：
接管领取后果音讯
付款是批量付款，一个付款对应多个付款详情，须要对多个供应商付款。
因为同时付款所以领取后果 mq 根本也是同时接管到。
业务诉求，当领取详情都收到领取后果后，领取单状态变为领取实现。
亮点：
解决计划，以付款单 id 为纬度进行加锁。
不加锁结果：有 A、B 两个领取 详情，线程 1 收到领取胜利音讯，更新 A 为领取胜利，查问是否所有都已领取胜利，这时 B 尚未领取胜利，所以不更新付款单状态为领取实现；在 A 线程提交事务前，线程 2 收到 B 领取胜利音讯，更新 B 为领取胜利，而后查问是否都已领取，因为此时 A 线程尚未提交，所以查问的是 A 线程还未领取，不更新付款单状态。最终造成付款单状态不可能变为领取实现。
发动领取时：
1. 调用近程转账接口发动领取，发动失败，整体事务不回滚，会记录以后发动领取失败状态；调用领取接口超时同时也是记录发动领取失败状态。
2. 转账接口会依据传的全局惟一号做幂等，反对反复发动。每个领取详情与一个全局惟一号绑定。
3. 会有定时工作定时扫描，发动失败的数据，从新调用转账接口进行领取。
4. 为防止同时发动领取，发动领取依据付款单 id 进行加锁。
5. 先保留领取详情和转账全局惟一幂等号的关联关系，并设置状态为转账发动中；再调用转账接口，再更新领取详情状态为发动胜利或者失败。起因：发动状态在调用接口后才晓得，如果调用接口胜利了，然而保留本地失败了，再转账会生成新的转账幂等号，会反复转账。
6. 为什么不实用付款详情的编号作为转账的幂等号？因为转账失败的话，能够再此付款详情中再发动转账，如果应用付款详情的编号，再次发动，转账接口端判断之前解决过了不会再解决。