003 分布式事务解决方案存在的问题

分布式系统一致性解决方案

        CAP和BASE理论为基础，我们回过头来再去看看Q1的问题，针对订单表和库存表，我们可以对每一个步骤都去记录其状态，有问题时可以根据所记录的状态来继续执行任务，最终达到一致性，这种方法比如使用定时任务来捞取未知的状态进行处理即可，而下游服务只需满足幂等性就可以达到目的。所以还要一种理论就是酸碱平衡理论，就是说我们可以使用数据库的强一致性和BASE理论的弱一致性结合的方式来处理分布式场景中的一些实际问题。 （结合使用才是合理方案）

幂等性：一条update语句，根据ID进行更新，如果产生并发请求，无论多少并发，只保证其中一条成功；在更删改前要先查询出版本号，再将版本号作为修改条带入语句，完成操作后版本号+1了，其他线程无对应版本号就无法修改最终失败，这就是乐观锁方式；

了解了ACID/CAP/BASE这些业界著名理论以后，再来看看通常分布式服务、分布式事务，在业界中都有那些解决方案：

•两阶段提交协议

•三阶段提交协议

•使用MQ处理分布式业务场景

•TCC柔性事务方案

 

两阶段提交协议、三阶段提交协议（2pc、3pc）

•JEE的XA协议是根据两阶段提交来保证事务的完整性的，并且可以实现分布式服务化的强一致性。

•两阶段提交，顾名思义分为两个阶段，一个是准备阶段，一个是提交阶段。准备和提交阶段都是由另外一个事务管理器发起的，我们可以来看一个文章说明一下问题。

•参考文章地址：http://blog.jobbole.com/95632/ 

使用MQ处理分布式业务场景

        对于RocketMQ 他是目前唯一支持分布式事物的消息中间件，他是具体如何实现的呢，看一篇文章，了解下。

•文章地址：https://www.jianshu.com/p/453c6e7ff81c

TCC柔性事务（不推荐，非常麻烦，不好用，开发成本过高）

        TCC，对于阿里所提出的柔性事务，网上各种版本，各不一致，有的生涩难懂，阅读之后让其更受困扰，变得更为复杂化，在这里我们详细来讲讲TCC的概念。

        TCC你可以理解为是专门针对于分布式场景的一种实现策略或者说协议，TCC把一个分布式的请求任务拆分成了Try、Confirm、Cancel三个步骤，正常的流程肯定先会执行Try，如果执行没问题，再执行Confirm，如果执行过程中出现了超时或者异常等问题，则执行Cancel操作。从正常的角度去想，这仍然是一种两阶段提交协议的思想，但是其好处是在执行出现问题之后有一定的自我恢复能力，如果任何参与者出现了问题则协调者通过执行操作的逆向操作来回滚之前的所有操作，从而达到最终一致状态。当然TCC也有它的问题所在，在极端情况下，可能出现有些参与者收到命令，有些没有收到命令的时候，那么系统首先就会通过自动补偿的方式尝试自动修复或者重试，如果无法修复成功则只能由人工参与解决。