文章目录
-
- 0.简介
- 1.基础知识
-
- [1.1 共识和一致性](#1.1 共识和一致性)
- [1.2 一致性介绍](#1.2 一致性介绍)
-
- [1.2.1 强一致性](#1.2.1 强一致性)
- [1.2.2 弱一致性](#1.2.2 弱一致性)
- [1.3 共识介绍](#1.3 共识介绍)
-
- [1.3.1 拜占庭容错](#1.3.1 拜占庭容错)
- [1.3.2 非拜占庭容错](#1.3.2 非拜占庭容错)
- 2.一致性算法
-
- [2.1 2PC && 3PC](#2.1 2PC && 3PC)
-
- [2.1.1 2PC](#2.1.1 2PC)
- [2.1.2 3PC](#2.1.2 3PC)
- [2.2 TCC](#2.2 TCC)
- [2.3 Gossip](#2.3 Gossip)
- 3.Paxos
0.简介
开发分布式系统过程中最为关键的就是根据其不同的场景特点去选择合适的算法，而本文将介绍多种分布式一致性和共识算法，包含对常见共识算法（Raft,Paxos）和一致性算法（2PC,TCC,Gossip）的简要分析。
1.基础知识
1.1 共识和一致性
在分布式理论中，最为关键的问题就是共识和一致性。共识就是如何保证多个节点对于一个事务得到统一的结论。而一致性就是如何保证多副本或者多节点上数据一致。下面对这两个问题进行详细分析。
1.2 一致性介绍
要讲一致性，就要明白一致性的分类。
1.2.1 强一致性
对一致性要求最高，需要每次写操作后，所有后续的访问都能得到更新后的值，因为是同步的，一般来说性能会比较低，一般金融领域使用较多。其可以详细分为线性一致性和顺序一致性。
线性一致性：线性一致性又被称为强一致性、严格一致性、原子一致性。是程序能实现的最高的一致性模型，也是分布式系统用户最期望的一致性。简单说就是一个写入操作后，所有读取操作都应该返回相同的结果。需要满足的三个约束：
1）所有进程看到的操作都要和全局时钟顺序一致。
2）操作都被立即执行。（瞬间执行，原子执行）。
3）所有读操作都读到数据最近一次写，后续读操作结果一致，直到下次写操作。
可以看到，其对全局时钟一致性有着较高的要求。
顺序一致性：顺序一致性和线性一致性相比，线性一致性要求全局都必须有顺序，而顺序一致性只要求单个进程顺序确定即可，即上图如果是顺序一致性可以是A1->A2->B1->B2也可以是A1->B1->A2->B2。
1.2.2 弱一致性
弱一致性在写操作完成后并不能保证所有的后续访问都是最新的，主要介绍最终一致性。最终一致性的分支有很多，是根据问题场景的权衡。
1）因果一致性：保证其按照逻辑顺序，比如问答，要有出现的逻辑顺序。
2）读己所写一致性：确保读自己写的数据。
3）会话一致性：保证整个会话读到的顺序一致。
4）单调读一致性：不会读到比已经读到的值更旧的值。
5）单调写一致性：写操作对于一个客户端来说在所有副本上顺序一致。
1.3 共识介绍
要了解共识算法，首先先了解一个广为传播的问题，即拜占庭将军问题：拜占庭罗马帝国国土辽阔，为了达到防御目的，每个军队都分隔很远，将军与将军之间只能靠信差传消息。在战争的时候，拜占庭军队内所有将军和副官必须达成一致的共识，决定是否有赢的机会才去攻打敌人的阵营。但是，军队内有可能存有叛徒和敌军的间谍，他们会左右将军们的决定并扰乱整体军队的秩序。在进行共识时，结果并不代表大多数人的意见。这时候，在已知有成员谋反的情况下，其余忠诚的将军如何在不受叛徒的影响下达成一致的协议，拜占庭问题就此形成。
总结一下，拜占庭问题主要目的就是让每位将军的消息能够正确到达其他将军那里，并且产生多数/少数的情况，以此达到一个共识。这样各节点才能做出正确的决策，以拜占庭问题为基础可以分为拜占庭容错和非拜占庭容错。
1.3.1 拜占庭容错
拜占庭错误是一个错误模型，描述了一个完全不可信的场景，除了存在故障行为，还存在恶意行为。拜占庭容错（Byzantine Fault Tolerance，BFT），就是指能容忍拜占庭错误了。拜占庭容错是分布式领域最复杂的容错模型，是你必须要了解的。在一个完全不可信的环境中（比如有人作恶），如果需要达成共识，那么我们就必须考虑拜占庭容错算法，常用的拜占庭容错算法有 POW 算法、PBFT 算法，它们在区块链中应用广泛。从概率角度，PBFT 系列算法是确定的，一旦达成共识就不可逆转；而 PoW 系列算法则是不确定的，随着时间推移，被推翻的概率越来越小。
1.3.2 非拜占庭容错
又叫故障容错（Crash Fault Tolerance，CFT），解决的是分布式系统中存在故障，但不存在恶意节点的共识问题。实际上，这种故障是非常场景的，比如进程奔溃、服务器硬件故障、网络中断、响应延迟等等。针对非拜占庭错误的解决方案，业界一般采用 Paxos、Raft 及其各种变种的协议。
2.一致性算法
2.1 2PC && 3PC
2.1.1 2PC
两阶段提交时非常经典的强一致性协议，其流程就是第一阶段做投票，第二阶段做决定。
1）准备阶段：事务管理器给每个参与者发送prepare消息，每个参与者执行本地事务并写本地日志，此时事务并没有提交。
2）提交阶段：事务管理器根据参与者执行的状态发送回滚或提交消息。
2.1.2 3PC
三阶段提交是基于二阶段提交的扩展，主要解决了二阶段提交的阻塞问题，增加到了三个阶段，同时增加超时机制。
1）Can Commit阶段：向所有参与者发送是否可以提交事务的请求。
2）PreCommit: 事务预提交，写本地日志。
3）DoCommit：真正提交。
2.2 TCC
TCC（Try-Confirm-Cancel)，其核心的思想就是：每个操作都要注册一个对应的确认和撤销处理。可以分为三个操作：
1）Try:去对业务系统做检测和资源预留。
2）Confirm:确认执行业务操作。
3）Cancel：取消业务操作。
可以看到其流程和2PC类似，TCC本质上就是一个应用层面的2PC,需要通过业务逻辑来实现，可以自己定义操作粒度，增大吞吐量，但其对应用有着较强的侵入。
2.3 Gossip
Gossip是一种利用随机和带传染性的方式，将信息传播到整个网络，并在一定时间内，保证系统内所有数据节点数据一致的最终一致性的协议。其主要包括两种类型：
1）Anti-Entropy（反熵）：以固定的概率传播所有的数据。
2）Rumor-Mongering（谣言传播）：仅传播新到达的数据。
3.Paxos
Paxos 算法基本上来说是个民主选举的算法------大多数的决定会成个整个集群的统一决定。任何一个点都可以提出要修改某个数据的提案，是否通过这个提案取决于这个集群中是否有超过半数的结点同意（所以Paxos算法需要集群中的结点是单数）。兰伯特提出的 Paxos 算法包含 2 个部分：
-
Basic Paxos 算法，描述的是多节点之间如何就某个值（提案 Value）达成共识；
-
另一个是 Multi-Paxos 思想，描述的是执行多个 Basic Paxos 实例就一系列值达成共识。Basic Paxos 是 Multi-Paxos 思想的核心。
其Raft是其变种，更利于实现。可以看Raft的介绍。