分布式系统题目答案(2)
6、分布式事务的解决方案
分布式事务是指一个事务包含多个操作，这些操作分布在不同的服务器上，要么都成功，要么都失败。
分布式事务问题的主要来源
1、存储，分库分表跨库增删改时，保证数据的一致性
2、服务拆分，一个操作依赖多个服务，一个服务失败就影响了整体的操作分布式事务解决方案
2PC 两阶段提交，两个阶段：准备与提交；两个角色：事务管理者与资源管理者。容易产生同步阻塞、单点故障、数据不一致等问题，并不能完全保证事务的一致性。
3PC 三阶段提交，三阶段：预备、准备、提交。与二阶段提交相比，加入了超时机制解决同步阻塞的问题；加入预备阶段提早发现问题。三阶段提交也存在极小概率的数据不一致问题。
TCC 模式，分为三个操作：Try、Confirm、Cancel。TCC 是分为两个阶段提交。第一阶段主业务服务调用全部的从业务服务的 Try 操作，并且事务管理器记录操作日志；第二阶段，当全部从业务服务都成功时，直接执行 Confirm 操作，否则会执行 Cancel 逆操作进行回滚。
Saga 模式，拆分分布式事务为多个本地事务，然后由 Saga 引擎负责协调。比 TCC 少了一个 Try 操作，Saga 会直接提交到数据库，出现失败时进行补偿。极端情况下的补偿动作可能比较麻烦；但对于简单的业务逻辑侵入性更低，减少了通信次数，更轻量。
补偿模式，通过补偿的方式让数据最终一致。方式有：操作幂等 + 重试机制 + 人工介入机制；定时校对；网络抖动和服务不可用导致的情况，可使用下次更新前，检查和修复上一次数据的更新。
可靠事件模式，通过引入可靠的消息队列，保证当前的可靠事件投递并且消息队列确保事件传递至少一次，这个事件能够被订阅者消费即可。未操作或未消费消息的持久化、消息的幂等性、消息的重发、消息的 ACK 都是要注意的问题。
不要求最终一致性的柔性事务，会尽最大努力通知。
7、解决分布式事务的开源组件
阿里开源组件 Seata，分为全局事务和分支事务，分支事务满足 ACID 特性，全局事务基于二阶段提交对分支事务进行协调；同时也满足上述的几种模式。
http://seata.io/zh-cn/docs/overview/what-is-seata.html
tcc-transaction 框架是 TCC 模式的一种实现，tcc-transaction 的使用
https://github.com/changmingxie/tcc-transaction
华为 ServiceComb 框架的 Saga 模块：
https://github.com/apache/servicecomb-pack/blob/master/README_ZH.md
8、三阶段提交比二阶段提交的改进
两阶段提交：
提交请求(Commit-request)阶段，协调者将通知事务参与者执行事务但不提交，参与者反馈是否可以正常提交。
提交(Commit)阶段，协调者将基于第一个阶段的反馈结果进行决策，提交或回滚这个事务；只有当所有的参与者同意提交，协调者才会通知各个参与者提交事务，否则协调者将通知各个参与者回滚事务
两阶段提交存在的问题：
资源被同步阻塞
协调者可能出现单点故障
Commit 阶段发出 commit 通知，但网络抖动可能导致出现数据不一致
三阶段提交：
CanCommit 阶段，协调者询问参与者是否可以正常提交，此阶段不执行仅评估与反馈，反馈 no 或超时直接终止。
PreCommit 阶段，所有参与者反馈可提交，进行事务的预提交；否则反馈 no 或超时，中断事务。
DoCommit 阶段，事务提交；协调者没接收到或接收超时中断事务；参与者接受协调者提交请求超时自动提交
三阶段提交进行了改进：
协调者与参与者都引入了超时机制，解决同步阻塞问题
添加预提交阶段，锁定资源前进行了预判，提早发现问题
三阶段提交依然存在数据不一致的问题，如网络问题 DoCommit 阶段接收者接收超时自动提交，其余节点回滚，此时就会产生数据不一致。