分布式事务

什么是分布式系统？

​ 分布式系统是若干独立计算机的集合，这计算机对用户来说就像单个相关系统。

分布式系统的优点

• 应用分层(模块化)：系统可按业务类型拆分成多个应用，按照结构还可分为接口层、服务层等。
• 增大系统的容量：多个服务多个应用，分开处理不同的业务
• 高可用性：系统的高度可用性，单个系统故障并不影响整体。
• 提高系统可扩展性
• 提高开发及发布速度

分布式系统的缺点

• 架构设计变得复杂化：分布式事务、分布式锁、分布式session、数据一致性等
• 增加了开发测试运维成本，工作量增加
• 系统的吞吐量会变大，但是响应时间会变长
• 测试和查错的复杂度增大

分布式事务基础

​ CAP 定理，又被叫作布鲁尔定理

​ CAP定理，同时只能满足其中两条，无法同时满足所有定理

• Consistency（一致性）:所有的事务获取的数据都应该是最终事务提交的状态。
• Availability（可用性）:只是意味着服务是可用的，单个服务故障不影响整体应用的运转。
• Partition tolerance（分区容错性）:系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择

事务的基本特性(ACID)

• 原子性(Atomicity)：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节
• 一致性(Consistency)：在一个事务执行之前和执行之后数据库都必须处于一致性状态
• 隔离性(Isolation)：在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间
• 持久性(Durability)：只要事务成功结束，它对数据库所做的更新就必须永久保存下来

BASE 原则

​ BASE (basically available, soft state, eventually consistent)：是对 CAP 中 AP 的一个扩展，解决了 CAP 中理论没有网络延迟，在 BASE 中用软状态和最终一致，保证了延迟后的一致性。BASE 和 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态

• Basically Available(基本可用)：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用
• Soft state(软状态):允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是 CAP 中的不一致
• Eventually consistent (最终一致性)：最终一致是指经过一段时间后，所有节点数据都将会达到一致

常见的分布式事务处理方案

2PC（Two-phase Commit）：二阶段提交

​ 在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等).

参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作

• 阶段1:请求阶段（commit-request phase，或称表决阶段，voting phase）

事务协调者向所有参与者发起prepare，所有参与者回答yes/no

• 阶段2：提交阶段（commit phase）

如果所有参与者都回答yes，则向所有参与者发起commit；否则，向所有参与者发起rollback

实现2pc，所有参与者，都得实现3个接口：prepare/commit/rollback

• 2PC所存在的问题
  • 同步阻塞问题：它的执行过程中间，节点都处于阻塞状态。即节点之间在等待对方的相应消息时，它将什么也做不了。特别是，当一个节点在已经占有了某项资源的情况下，为了等待其他节点的响应消息而陷入阻塞状态时，当第三个节点尝试访问该节点占有的资源时，这个节点也将连带陷入阻塞状态
  • 单点故障：事务协调者挂了，则所有参与者接受不到commit/rollback指令，参与者会一直阻塞下去
  • 其中一个参与者超时或者出错，那其他参与者，是commit，还是rollback呢

TCC（Try-Confirm-Cancel）

​ 每个参与者需要3个操作：Try/Confirm/Cancel

​ 2个阶段

• 阶段1:资源预留/资源检查,事务协调者调用所有参与者的Try操作

• 阶段2:所有的Try成功，一起执行Confirm。否则，所有的执行Cancel

关键：Try阶段成功之后，Confirm如果失败(不管是协调者挂了，还是某个参与者超时），不断重试！！ 同样，Cancel失败了，也是不断重试。这就要求Confirm/Cancel都必须是幂等操作

• Try ：尝试执行，完成所有业务检查（一致性），预留必需业务资源（准隔离性）
• Confirm ：确认真正执行业务，不作任何业务检查，只使用 Try 阶段预留的业务资源，Confirm 操作满足幂等性。要求具备幂等设计，Confirm 失败后需要进行重试
• Cancel ：取消执行，释放 Try 阶段预留的业务资源，Cancel 操作满足幂等性。Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致

消息事务