分布式事务的解决方案(介绍其中三种)
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对账稽核流程保证最终一致性，订单状态根据对账结果流转为：已完成或待退款–>退款成功。
