分布式一致性原理笔记

CAP 定理

C: Consistency A: availability P: Partition tolerance

Consistency (一致性）在分布式环境下，数据在多个副本之间保持一致性。
如果对一个数据项的更新操作执行成功后，所有的用户可以读到其最新的值，那么这样的系统被认为具有强一致性(严格一致性）。
Availability (可用性) 对于用户的一个请求，系统必须在指定的时间内返回对应的处理结果。
Partition tolerance ( 分区容错性）: 分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

CAP 定理：一个分布性系统不可能同时满足一致性、可用性和分区容错性。

Base 理论

Basically Available（基本可用），Soft state(软状态）和 Eventually consistent (最终一致性）
核心思想：无法做到强一致性，但每个应用可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（eventual consistency)

基本可用性：分布式系统出现不可预知故障时候，允许损失部分可用性
响应时间上的损失
功能上的损失：降级
软状态：允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延迟。
最终一致性： 强调系统中的所有数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。

工程实践中，最终一致性存在一下5类变种：
1. 因果一致性
2. 读己之所写
3. 会话一致性
4. 单调一致性
5. 单调写一致性

2PC 两二阶段提交协议

阶段一： 提交事务请求
1. 事务询问
协调者向所有的参与者发生事务内容，询问是否可以执行事务执行操作。
2. 执行事务。
3. 各参与者节点执行事务操作，并将undo 和 redo 信息记录入事务日志中。
4. 各参与者向协调者反馈事务询问的响应。

阶段二：执行事务的提交
1. 协调者发送提交请求
2. 参与者正式执行事务提交操作
3. 参与者反馈事务提交结果，向协调者发送Ack 消息
4. 协调者完成事务。

二阶段提交协议缺点：

• 同步阻塞
• 单点故障
• 数据不一致性
• 太过保守

3PC 三阶段提交
3PC的核心理念是先询问，若所有人都同意，则锁定资源，在开始尝试执行、提交。

优点：
和2PC相比较而言，3PC降低了参与者的阻塞范围，能在出现单点故障后继续达成一致，参与者如果在不同阶段宕机，我们来看看3PC如何应对：

阶段1: 协调者未收到宕机参与者的vote，直接中止事务；宕机的参与者恢复后，读取logging发现未发出赞成vote，自行中止该次事务。因为先询问，此时并没有锁住资源，避免了2PC第一阶段若已经由节点宕机，其他节点无谓的阻塞。
阶段2: 协调者未收到宕机参与者的precommit ACK，但因为之前已经收到了宕机参与者的赞成反馈(不然也不会进入到阶段2)，协调者进行commit；宕机的participant恢复后发现收到precommit或已经发出赞成vote，则自行commit该次事务
阶段3:即便协调者未收到宕机参与者的commit ACK，也结束该次事务；宕机的参与者恢复后发现收到commit或者precommit，也将自行commit该次事务。

2PC与3PC的区别
相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。（其实这个应该是基于概率来决定的，当进入第三阶段时，说明参与者在第二阶段已经收到了PreCommit请求，那么协调者产生PreCommit请求的前提条件是他在第二阶段开始之前，收到所有参与者的CanCommit响应都是Yes。（一旦参与者收到了PreCommit，意味他知道大家其实都同意修改了）所以，一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到commit或者abort响应，但是他有理由相信：成功提交的几率很大。 ）