如何实现分布式事务

什么是分布式事务？

简单的说，就是一次大操作由不同小操作组成，这些小操作分布在不同服务器上，分布式事务需要保证这些小操作要么全部成功，要么全部失败。
你上淘宝买东西，需要先扣钱，然后商品库存-1吧。但扣款和库存分别属于两个服务，这两个服务中间要经过网络、网关、主机等一系列中间层，万一任何一个地方出了问题，比如网络抖动、突发异常等待，都会导致不一致，比如扣款成功了，但是库存没-1，就会出现超卖的现象，而这就是分布式事务需要解决的问题。

分布式事务的应用场景？

1)电商系统中的下单扣库存
电商系统中，订单系统和库存系统是两个系统，一-次下单的操作由两个系统协同完成
2)金融系统中的银行卡充值
在金融系统中通过银行卡向平台充值需要通过银行系统和金融系统协同完成。
3)教育系统中下单选课业务
在线教育系统中，用户购买课程，下单支付成功后学生选课成功，此事务由订单系统和选课系统协同完成。
4) SNS系统的消息发送
在社交系统中发送站内消息同时发送手机短信，- -次消息发送由站内消息系统和手机通信系统协同完成。

CAP理论

如何进行分布式事务控制？CAP理论是分布式事务处理的理论基础
CAP理论是：分布式系统在设计时只能在一致性(Consistency)、可用性(Availability)、
分区容忍性(Partition Tolerance)中满足两种，无法兼顾三种。

一致性:
服务A、B、C三个结点都存储了用户数据， 三个结点的数据需要保持同一时刻数据一致性。
可用性:
服务A、B、C三个结点，其中一个结点宕机不影响整个集群对外提供服务，如果只有服务A结点，当服务A宕机整个系统将无法提供服务，增加服务B、C是为了保证系统的可用性。
分区容忍性:
分区容忍性就是允许系统通过网络协同工作，分区容忍性要解决由于网络分区导致数据的不完整及无法访问等问题。分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

分布式系统能否兼顾C、A、P？

在保证分区容忍性的前提下一致性和可用性无法兼顾，如果要提高系统的可用性就要增加多个结点，如果要保证数据的一致性就要实现每个结点的数据一致，结点越多可用性越好，但是数据一致性越差。所以，在进行分布式系统设计时，同时满足“一致性”、“可用性”和“分区容忍性”三者是几乎不可能的。
CAP有哪些组合方式？
1、CA：放弃分区容忍性，加强一致性和可用性，关系数据库按照CA进行设计。
2、AP：放弃一致性，加强可用性和分区容忍性，追求最终一致性，很多NoSQL数据库按照AP进行设计。说明：这里放弃一致性是指放弃强一致性，强一致性就是写入成功立刻要查询出最新数据。追求最终一致性是指允许暂时的数据不一致，只要最终在用户接受的时间内数据 一致即可
3、CP：放弃可用性，加强一致性和分区容忍性，一些强一致性要求的系统按CP进行设计，比如跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完
成。​ 说明：由于网络问题的存在CP系统可能会出现待等待超时，如果没有处理超时问题则整理系统会出现阻塞
总结：​ 在分布式系统设计中AP的应用较多，即保证分区容忍性和可用性，牺牲数据的强一致性（写操作后立刻读取到最新数据），保证数据最终一致性。比如：订单退款，今日退款成功，明日账户到账，只要在预定的用户可以接受的时间内退款事务走完即可。

分布式事务解决方案
基于XA协议的2PC（二阶段提交）
XA是一个分布式事务协议。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚
2阶段提交是分布式事务传统解决方案，现在为止还广泛存在。当一个事务跨越多个节点时，为了保持事务ACID特性，需要引入一个协调者来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
以开会为例
甲乙丙丁四人要组织一个会议，需要确定会议时间，不妨设甲是协调者，乙丙丁是参与者。
投票阶段
甲发邮件给乙丙丁，周二十点开会是否有时间；
丁回复有时间；
乙回复有时间；
丙迟迟不回复，此时对于这个活动，甲乙丙均处于阻塞状态，算法无法继续进行；
丙回复有时间（或者没有时间）；
提交阶段
协调者甲将收集到的结果反馈给乙丙丁（什么时候反馈，以及反馈结果如何，在此例中取决
于丙的时间与决定）；
乙收到；
丙收到；
丁收到；

缺点：不仅要锁住参与者的所有资源，而且要锁住协调者资源，开销大。一句话总
结就是：2PC效率很低，对高并发很不友好

3PC(三阶段提交)

与两阶段提交不同的是，三阶段提交有两个改动点。
1、引入超时机制。同时在协调者和参与者中都引入超时机制。2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与
节点的状态是一致的。也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再
次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

阶段一：CanCommit
事务询问 执行者向所有参与者发送CanCommit请求，等待所有参与者的响应
参与者反馈响应 参与者节点若认为自身可以完成事务，返回Yes；反之，返回No
阶段二：PreCommit
若所有参与者反馈的结果都是Yes响应，那么进行事务预提交
若任意一个参与者反馈的结果是No响应，或者在等待超时之后，那么执行事务中断
阶段三：doCommit
该阶段可能存在两种情况，执行事务的提交和中断事务
若执行者接受到所有参与的Ack响应，那么执行事务提交
如果有任意一个参与者反馈No响应，或者在等待超时之后，执行中断事务

TCC(事务补偿)

所谓的TCC编程模式，也是两阶段提交的一个变种。TCC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个操作。以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。总之，TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。

LCN框架官网地址：http://www.txlcn.org/zh-cn/

LCN分布式事务框架的核心功能是对本地事务的协调控制，框架本身并不创建事务，只是对本地事务做协调控制。LCN框架主要是为微服务框架提供分布式事务的支持，在微服务框架上做了进一步的事务机制优化。

柔性事务
所谓柔性事务是相对强制锁表的刚性事务而言。流程如下：服务器A的事务如果
执行顺利，那么事务A就先行提交，如果事务B也执行顺利，则事务B也提交，整个事
务就算完成。但是如果事务B执行失败，事务B本身回滚，这时事务A已经被提交，所
以需要执行一个补偿操作，将已经提交的事务A执行的操作作反操作，恢复到未执行
前事务A的状态。

缺点是业务侵入性太强，还要补偿操作，缺乏普遍性，没法大规模推广。

消息最终一致性解决方案之RocketMQ

采用最终一致性原理。
需要保证以下三要素:
1、确认生产者一定要将数据投递到MQ服务器中（采用MQ消息确认机制）
2、MQ消费者消息能够正确消费消息，采用手动ACK模式（注意重试幂等性问题）
3、如何保证第一个事务先执行，采用补偿机制，在创建一个补单消费者进行监听，如果订
单没有创建成功，进行补单。(如果第一个事务中出错，补单消费者会在重新执行一次第一个
事务，例如第一个事务是添加订单表，如果失败在补单的时候重新生成订单记录，由于订单号
唯一，所以不会重复)

经典案例，以目前流行点外卖的案例，用户下单后，调用订单服务，让后订单服务调用派单系
统通知送外卖人员送单，这时候订单系统与派单系统采用MQ异步通讯。

MQ解决分布式事务一致性
案例中 订单表 和 派单表必须一致！