CAP 理论

• 一致性（Consistency）

  分布式系统中所有数据备份，在同一时刻是否是同样的值

• 可用性（Availability）

  集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求

• 分区容错性（Partition tolerance ）

  大多数分布式系统都分布在多个子网络，每个子网络叫做一个区（partition）。分区容错是指区之间的通信可能失败

CAP 原则指的是这三个要素只能实现两点，不可能三者兼顾。在分布式系统中，一般来说分区容错性不可避免，所以 P 总是成立的，C 和 A 无法同时做到

如何实现一致性

raft 算法

Raft

paxos 算法

结论

对于多数大型互联网应用的场景，节点众多、部署分散，由于现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到 N 个 9（99.99..%），并要达到良好的响应性能来提高用户体验，因此一般都会做出如下选择：保证 P 和 A，舍弃 C 强一致，保证最终一致性

Base 理论

• Basically Available（基本可用）

  基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性），允许损失部分可用性。需要注意的是，基本可用绝不等价于系统不可用

  • 响应时间上的损失：正常情况下搜索引擎需要在 0.5 秒内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了 1 ~ 2 秒

  • 功能上的损失：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面

• Soft State（软状态）

  软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本同步的延时就是软状态的体现。mysql replication 的异步复制也是一种体现

• Eventual Consistency（最终一致性）

  最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况

  • 强一致性：更新过据后，所有节点立刻能看到更新后的数据

  • 弱一致性：更新过据后，能容忍部分节点看不到更新后的数据

  • 最终一致性：一段时间后，所有节点都能看到更新后的数据

分布式事务场景

• 跨 JVM 进程：微服务之间通过远程调用完成事务操作。 比如电商系统中提交订单，订单微服务请求库存微服务扣减库存，请求会员微服务增加积分，在分布式系统中经常发生网络异常、机器宕机导致请求失败，如果库存服务扣减库存成功后宕机了，订单服务就会回滚，造成数据的不一致

• 跨库：比如做了订单数据做了分库之后的更新操作，订单数据落在不同的库中，如果更新失败必须全部回滚

• 跨数据库实例

分布式事务角色

• TM（Transaction Manager）：事务管理者。负责协调和管理事务，事务管理器控制着全局事务，管理事务生命周期，并协调各个 RM

• RM（Resouce Manager）：资源管理者。可以理解为事务的参与者，一般情况下是指一个数据库实例，控制着分支事务

• TC（Tracnaction Coordinator）：全局事务的协调者

分布式事务方案

2PC 模式

2PC 即两阶段提交协议，是将整个事务流程分为两个阶段：准备阶段（Prepare phase）和提交阶段（Commit phase）

2PC 是一种强一致性设计，它引入一个协调者来协调管理各参与者的提交和回滚

• 准备阶段（Prepare phase）

  1. 协调者向所有参与者发送 prepare 消息，询问是否可以提交事务，并等待答复

  2. 每个事务参与者在本地执行事务，并写本地的 undo/redo 日志，此时事务没有提交

     undo 日志是记录修改前的数据，用于数据库回滚；redo 日志是记录修改后的数据，用于提交事务后写入数据文件

  3. 如参与者执行成功，给协调者反馈同意，否则反馈中止

  

• 提交阶段（Commit phase）

  1. 协调者节点向所有参与者节点发送 commit 消息，让各参与者正式提交

  2. 参与者节点完成提交，并释放在整个事务期间内占用的资源

  3. 参与者节点向协调者节点发送 ack 完成消息

  4. 协调者节点收到所有参与者节点反馈的 ack 完成消息后，完成事务

  

XA 协议

XA 协议是 X/OPEN 提出的分布式事务处理规范，它规范了 TM 与 RM 之间的通信接口。部分关系数据库如 Oracle、MySQL 都支持 XA 协议

优缺点

优点：

• 开发成本低：XA 协议比较简单，如果商业数据库实现了 XA 协议，使用分布式事务的成本比较低

缺点：

• 性能问题：XA 协议性能差，类似交易下单链路并发量很高，无法支持高并发场景

• 可靠性问题：在提交阶段协调者宕机，参与者会一直阻塞下去，需要额外的备机进行容错

• 数据一致性问题：协调者向参与者发送 commit 消息之后，发生了局部网络异常或者协调者宕机了，导致只有一部分参与者接收到了 commit 消息，其他部分未接收到 commit 消息的参与者则无法执行事务提交，于是整个分布式系统便出现了数据不一致

3PC 模式

• 相比 2PC 模式，准备阶段进一步拆分了准备阶段和预提交阶段

• RM 引入了超时机制

柔性事务-TCC 事务补偿

TCC（Try Confirm Cancel） 方案是一种应用层面侵入业务的两阶段提交，可以理解为手动的 2PC。其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿操作

• Try 阶段

  • 完成所有业务检查

  • 预留必须的业务资源

  • 尝试执行业务

• Confirm/Cancel 阶段

  • Confirm 和 Cancel 操作满足幂等性，如果 Confirm 或 Cancel 操作执行失败，将会不断重试直到执行完成

  • Try 阶段全部服务执行成功，进入 Confirm 阶段，执行确认业务逻辑操作

  • Try 阶段存在服务执行失败， 进入 Cancel 阶段，执行业务补偿操作

优缺点

优点：

• 性能提升：相比与 XA 协议，具体业务来实现控制资源，锁的粒度变小，性能更高

• 数据最终一致性：基于重试机制和 Confirm/Cancel 操作的幂等性，保证事务最终完成确认或者取消，保证数据的最终一致性

• 可靠性：解决了 XA 协议的协调者单点故障问题，

缺点：

• 业务侵入性高，开发成本高

最大努力通知

可靠消息