【JAVA】分布式事务

微信图片_20201124114812.png 微信图片_20201124114941.png 微信图片_20201124115021.png 微信图片_20201124115116.png

分布式事务的解决方案（介绍其中三种）
1.两阶段提交协议（2PC）
2.事务补偿（TCC）
3.消息队列实现最终一致

TCC (业务补偿和日志补偿)
业务补偿
try阶段预扣库存，commit阶段真正扣库存，cancel阶段恢复预扣的库存
日志补偿
先记日志，commit时删除日志，cancel时根据日志回滚

场景一：
库存数量与订单数量一致性，采用补偿型+最大努力通知型
1.先减库存，库存减成功后；
2.调用下单服务；
3.下单成功，两事务均提交完成；
4.下单失败，库存回滚，库存回滚失败，则放入消息服务（延时消息队列）分阶段定时重试，努力重试保证库存服务正常后成功回滚。

场景二：
订单信息、支付信息、充值信息三者之间的一致性，采用异步确保型的原因是，整个业务链路太长且跨不同的机房系统，网络延迟较高，业务方面恰好不需要非常高的实时性，所以采用小事务+异步通知，目前正常情况下用户从下单到完成支付到流量到账平均为1-5分钟左右：
1.下单成功即订单服务创建订单成功并发送支付请求到支付网关系统（订单状态-待支付，超过1小时未支付则流转为超时未付撤销，此处用到了RocketMQ的延时消费恰好实现定时器业务场景）。
2.返回支付页面，用户在支付交易系统完成支付业务流程，支付网关异步通知流量中心，流量中心接收到支付成功状态后修改订单状态-支付成功，并给支付网关返回成功结果。
3.流量中心修改完订单状态后，调用消息服务将直充业务放入消息队列，对直充业务进行解耦（原因是直充需要调用31省移动CRM系统，此链路过长，且部分省CRM系统耗时非常大，每个省的处理能力不同，经常出现20秒以上的超时，因此要考虑部分超时较高的省份拖垮系统，进行业务的削峰填谷）；
4.当直充成功时，修改订单状态-已完成；
5.当直充失败时（移动特性，例如：直充时正好用户销户或者停机了），修改订单状态为待退款，并调用支付网关系统的退款接口，退款成功后支付网关异步通知流量中心，流量中心修改订单状态为-退款成功；
6.当直充超时时，调用定时任务服务进行超时重试机制（第一次重试在10分钟后执行、第二次在30分钟后、第三次…..），直到最大超时重试次数后还得不到直充结果，订单状态会卡在支付成功状态，依赖T+1对账稽核流程保证最终一致性，订单状态根据对账结果流转为：已完成或待退款–>退款成功。

参考：
https://blog.csdn.net/oldshaui/article/details/88743085
https://www.cnblogs.com/bluemiaomiao/p/11216380.html
https://www.skypyb.com/2019/11/jishu/1171/