分布式一致性

ddatsh

dev #concurrent 2020/04/13

分布式系统面临的问题

• 通信异常

  不可用、延时、丢失

• 网络分区(脑裂)

  系统分化出两个网络组，组内都正常通讯，但组间通讯被阻隔

• 三态

  成功，失败和超时时（请求者无法判断当前请求是否成功处理）

• 节点故障

  宕机，僵死，器件损坏等

经典理论(CAP、BASE)

CAP

系统架构设计根据业务特点在C(一致性)和A(可用性)之间寻求平衡

BASE

BASE是对CAP中C和A权衡的结果逐步演化而来,来源于对大规模互联网系统分布式实践的总结

核心思想是即使无法做到强一致性(Strong consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)

一致性模型

• 严格一致性(强一致、原子一致、可线性化)
• 顺序一致
• 因果一致性
• 读己写
• 会话一致
• 单调一致

实际系统实践中,将若千个变种互相结合起来,构建一个具有最终一致性特性的分布式系统

复制状态机

在复制状态机模型下，一致性算法的主要工作就变成了如何保证操作日志的一致性

一致性算法

分布式系统都可以通过复制状态机模型来实现，而复制状态机模型又需要一致性协议来保证各个节点的日志写入顺序

2PC

如果协调者刚准备Commit时，发送了一个Commit请求给其中一个节点，这时候协调者和收到Commit的节点都挂了，其他节点就无法知道应当怎么做了,这时候他们会一直阻塞直到协调者恢复

而即便选取出新的协调者之后，这个新协调者也无法作出判断，因为可能存在潜在的节点已经Commit了相关内容，所以它要等所有节点都恢复之后，才能得出Commit或者Rollback的结论，而这整个过程中所有客户端都将阻塞

3PC

3将原来的Commit拆分成了PreCommit和Commit两个阶段

• CanCommit
• PreCommit
• DoCommit

如果协调者在PreCommit阶段有一个节点反馈了No，这时候协调者作出Abort的决定，并将Abort请求发送给其中一个节点A

A做完回滚操作后和协调者一起挂了，这时候新选出的协调者也没法明确之前的协调者最终作出了什么决定

3PC相对于2PC有了一个PreCommit状态作为参考，从而增大了猜对的可能性，因为正常来说，如果进入了PreCommit阶段那么所有节点都对CanCommit的决议作出了ACK的回应，那么它们对PreCommit作出ACK的回应的几率也会很大

去中心化的一致性算法

Multi-Paxos

原始Paxos（Basic Paxos）只能对一个值形成决议，决议的形成至少需要两次网络来回，极端情况下甚至可能形成活锁

Basic Paxos几乎只是用来做理论研究，并不直接应用在实际工程中

实际应用中几乎都需要连续确定多个值，而且希望能有更高的效率

Multi-Paxos在所有Proposers中选举一个Leader，由Leader唯一地提交Proposal给Acceptors进行表决

这样没有Proposer竞争，解决了活锁问题

在系统中仅有一个Leader进行Value提交的情况下，Prepare阶段就可以跳过，从而将两阶段变为一阶段，提高效率

raft