一 分布式事务
分布式事务指的是一个大的操作,有若干个小的操作组成,这些小的操作又分布在不同的服务器上面,并且这些小操作也属于不同的应用.
而分布式事务需要保证这些小的操作要么全部成功,要么失败回滚.本质上来说, 分布式就是为了保证不同数据库的数据一致性.
二 分布式事务的产生的原因
1 数据库分库分表
简单说就是把一个数据库变成多个数据库, 这个时候,如果一个操作既访问01数据库, 有访问02数据库, 而且要保证数据的一致性,那么此时就需要分布式事务来解决.
2 应用SOA化
所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。
以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了,需要保证数据的一致性,所以才需要采用分布式事务来解决这个问题.
三 分布式事务的解决方案
常见的解决方案:
两端提交协议(2pc), 三段提交协议(3pc), tcc补偿机制, 提供回滚接口, 分布式数据库
LNC核心采用3pc+TCC补偿机制
2pc两段提交
过程:第一阶段:准备阶段(投票阶段)
第二阶段:提交阶段(执行阶段)
在第一阶段:事务管理者给所有的参与者发送prepare 请求,参与者收到消息后准备执行事务并锁住需要的资源. 当参与者准备好后向事务管理者发送prepare ok请求.
若是有一个参与者返回no,则事务回滚.
在第二阶段:当事务管理者确定所有参与者都返回prepare ok后,再向所有的参与者发送commit请求,参与者commit之后,向事务管理者发送success请求.
3pc三阶段提价
三阶段提交是二阶段提交的改进版.
与二阶段不同的是,三阶段提价有两个改动点:
1.同时在协调者和参与者里面引入了超时机制.
2.在第一阶段和第二阶段插入了一个准备阶段,保证了在提交各阶段之前各参与节点的状态是一致的.
TCC
TCC将事务分为try和confirm/cancel两个阶段.
1、 在全局事务决定提交时，调用与try业务逻辑相对应的confirm业务逻辑；
2、 在全局事务决定回滚时，调用与try业务逻辑相对应的cancel业务逻辑。
MQ分布式事物
采用时效性高的 MQ，由对方订阅消息并监听，有消息时自动触发事件 采用定时轮询扫描的方式，去检查消息表的数据。
