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）
-
协调者向所有参与者发送 prepare 消息，询问是否可以提交事务，并等待答复
-
每个事务参与者在本地执行事务，并写本地的 undo/redo 日志，此时事务没有提交
undo 日志是记录修改前的数据，用于数据库回滚；redo 日志是记录修改后的数据，用于提交事务后写入数据文件
-
如参与者执行成功，给协调者反馈同意，否则反馈中止
-
-
提交阶段（Commit phase）
-
协调者节点向所有参与者节点发送 commit 消息，让各参与者正式提交
-
参与者节点完成提交，并释放在整个事务期间内占用的资源
-
参与者节点向协调者节点发送 ack 完成消息
-
协调者节点收到所有参与者节点反馈的 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 协议的协调者单点故障问题，
缺点：
-
业务侵入性高，开发成本高
