分布式

CAP

一致性（Consistency）

可用性（Availablility）

分区容错性（Partition tolerance）

• CP：

追求一致性和分区容错性：Redis、HBase、Zookeeper

• AP：

追求可用性和分区容错性：Eureka

---

BASE理论

BASE：基本可用（Basically Available）、软状态（Soft State）、最终一致性（Eventually Consistency）

基本可用：

分布式系统出现故障时，允许损失部分可用性，即保证核心可用

软状态：

允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

最终一致性：

系统中所有数据副本经过一段时间后，最终能够达到一致的状态。

---

分布式事务

2PC(Two-phaseCommit)：二阶段提交协议

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

• 准备阶段（投票阶段）

• 提交阶段（执行阶段）

缺点：

• 同步阻塞

• 单点故障

• 数据不一致

• 脑裂：Elasticsearch、Zookeeper 集群环境中，当两个机房之间的网络通信出现故障时，选举机制可能再两个计方选举出两个 Leader。

3PC(Three-phaseCommit)：三阶段提交协议

3PC 协议在 2PC 协议基础上加入了超时机制和 preCommit 阶段

• CanCommit 阶段

  和 2PC 的准备阶段相同，协调者像参与者发送 commit 请求，参与者收到请求后返回响应

• PreCommit 阶段

  如果所有的参与者都返回 Yes 响应，则执行事务的预执行

  1. 发送预提交请求：协调者向参与者发送 PreCommit 请求，并进入 Prepare 阶段
  2. 事务预提交：参与者收到 PreCommit 请求后，执行事务操作，并记录 undo log、redo log
  3. 响应反馈

  如果有任何一个参与者返回了 No 响应，或者等待超时后都没有接到参与者的响应，则执行事务中断

  1. 发送中断（abort）请求
  2. 终端事务

• doCommit 阶段

  在 doCommit 阶段如果参与者因为网络超时没有收到 doCommit 请求或者 abort 请求，则会继续进行事务的提交

---

分布式锁