分布式系统题目答案(2)

分布式事务是指一个事务包含多个操作，这些操作分布在不同的服务器上，要么都成功，要么都失败。

分布式事务问题的主要来源
1、存储，分库分表跨库增删改时，保证数据的一致性
2、服务拆分，一个操作依赖多个服务，一个服务失败就影响了整体的操作

分布式事务解决方案

• 2PC 两阶段提交，两个阶段：准备与提交；两个角色：事务管理者与资源管理者。容易产生同步阻塞、单点故障、数据不一致等问题，并不能完全保证事务的一致性。

• 3PC 三阶段提交，三阶段：预备、准备、提交。与二阶段提交相比，加入了超时机制解决同步阻塞的问题；加入预备阶段提早发现问题。三阶段提交也存在极小概率的数据不一致问题。

• TCC 模式，分为三个操作：Try、Confirm、Cancel。TCC 是分为两个阶段提交。第一阶段主业务服务调用全部的从业务服务的 Try 操作，并且事务管理器记录操作日志；第二阶段，当全部从业务服务都成功时，直接执行 Confirm 操作，否则会执行 Cancel 逆操作进行回滚。

• Saga 模式，拆分分布式事务为多个本地事务，然后由 Saga 引擎负责协调。比 TCC 少了一个 Try 操作，Saga 会直接提交到数据库，出现失败时进行补偿。极端情况下的补偿动作可能比较麻烦；但对于简单的业务逻辑侵入性更低，减少了通信次数，更轻量。
  

• 补偿模式，通过补偿的方式让数据最终一致。方式有：操作幂等 + 重试机制 + 人工介入机制；定时校对；网络抖动和服务不可用导致的情况，可使用下次更新前，检查和修复上一次数据的更新。

• 可靠事件模式，通过引入可靠的消息队列，保证当前的可靠事件投递并且消息队列确保事件传递至少一次，这个事件能够被订阅者消费即可。未操作或未消费消息的持久化、消息的幂等性、消息的重发、消息的 ACK 都是要注意的问题。

• 不要求最终一致性的柔性事务，会尽最大努力通知。

阿里开源组件 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

两阶段提交：

• 提交请求(Commit-request)阶段，协调者将通知事务参与者执行事务但不提交，参与者反馈是否可以正常提交。

• 提交(Commit)阶段，协调者将基于第一个阶段的反馈结果进行决策，提交或回滚这个事务；只有当所有的参与者同意提交，协调者才会通知各个参与者提交事务，否则协调者将通知各个参与者回滚事务

两阶段提交存在的问题：

• 资源被同步阻塞

• 协调者可能出现单点故障

• Commit 阶段发出 commit 通知，但网络抖动可能导致出现数据不一致

三阶段提交：

• CanCommit 阶段，协调者询问参与者是否可以正常提交，此阶段不执行仅评估与反馈，反馈 no 或超时直接终止。

• PreCommit 阶段，所有参与者反馈可提交，进行事务的预提交；否则反馈 no 或超时，中断事务。

• DoCommit 阶段，事务提交；协调者没接收到或接收超时中断事务；参与者接受协调者提交请求超时自动提交

三阶段提交进行了改进：

• 协调者与参与者都引入了超时机制，解决同步阻塞问题

• 添加预提交阶段，锁定资源前进行了预判，提早发现问题

三阶段提交依然存在数据不一致的问题，如网络问题 DoCommit 阶段接收者接收超时自动提交，其余节点回滚，此时就会产生数据不一致。