Spring Cloud分布式事务终极解决方案探讨

一 前言

本话题已收入视频讲座《Spring Cloud分布式事务解决方案》大家不妨围观下

阿里2017云栖大会《破解世界性技术难题！GTS让分布式事务简单高效》中，阿里声称提出了一种破解世界性难题之分布式事务的终极解决方案，无论是可靠性、还是处理速率都领先于市面上所有的技术。但令人遗憾的是一来项目未开源，二来还必须依赖阿里云的分布式数据库。毕竟，吃饭的家伙可不能轻易示人嘛。

虽然如此，但《世界难题...》一文中对事务还是归纳的还是蛮到位的:“一个看似简单的功能，内部可能需要调用多个“服务”并操作多个数据库或分片来实现，单一技术手段和解决方案已无法满足这些复杂应用场景。因此，分布式系统架构中分布式事务是一个绕不过去的挑战。

什么是分布式事务？简单的说，就是一次大操作由不同小操作组成，这些小操作分布在不同服务器上，分布式事务需要保证这些小操作要么全部成功，要么全部失败。”

举个栗子：

你上Taobao买东西，需要先扣钱，然后商品库存-1吧。但扣款和库存分别属于两个服务，这两个服务中间要经过网络、网关、主机等一系列中间层，万一任何一个地方出了问题，比如网络抖动、突发异常等待，都会导致不一致，比如扣款成功了，但是库存没-1，就会出现超卖的现象，而这就是分布式事务需要解决的问题

二 2阶段提交(2PC, 3PC等)

2阶段提交是分布式事务传统解决方案，先进为止还广泛存在。当一个事务跨越多个节点时，为了保持事务ACID特性，需要引入一个作为协调者来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

以开会为例

甲乙丙丁四人要组织一个会议，需要确定会议时间，不妨设甲是协调者，乙丙丁是参与者。

投票阶段

1. 甲发邮件给乙丙丁，周二十点开会是否有时间；
2. 甲回复有时间；
3. 乙回复有时间；
4. 丙迟迟不回复，此时对于这个活动，甲乙丙均处于阻塞状态，算法无法继续进行；
5. 丙回复有时间（或者没有时间）；

提交阶段

1. 协调者甲将收集到的结果反馈给乙丙丁（什么时候反馈，以及反馈结果如何，在此例中取决与丙的时间与决定）；
2. 乙收到；
3. 丙收到；
4. 丁收到；