分布式基本算法和理论（写了部分，后续再补充）

分布式协议和算法 路线 学习 四大基本理论 在学习 分布式协议和算法

四大基本理论

1 拜占庭将军问题
2 CAP 理论
3 ACID 理论
4 BASE 理论

八大分布式协议和算法

1 Paxos 算法
2 Raft 算法
3 一致性 Hash 算法
4 Gossip 协议算法
5 Quorum NWR 算法
6 FBFT 算法
7 POW 算法
8 ZAB 协议

拜占庭将军问题

大家可能听过拜占庭将军问题。它是由莱斯利·兰伯特提出的点对点通信中的基本问题

拜占庭解法1
具体问题和结果推到参见 文章
https://mp.weixin.qq.com/s?__biz=MzU4Mjk0MjkxNA==&mid=2247488050&idx=2&sn=7f2fa1d4add3dbbb494a291572541b7b&chksm=fdb1fb9fcac6728989d4a02d78da135942f90738d4e2ad474e664beb12bb2264406a90d48df6&scene=21#wechat_redirect

结论：
如果叛将人数为 m，将军数 n >= 3m + 1，那么就可以解决拜占庭将军问题。前提条件：叛将数 m 一致，需要进行 m + 1 轮的作战协商。

拜占庭解法2
那可以在不增加忠臣的情况下，解决拜占庭的二忠一判问题呢？

解法二就是通过签名消息。比如将军之间通过印章、虎符等信物进行通信。来保证这几个特征：
1 签名无法伪造，对签名消息的内容进行任何更改都会被发现。
2 任何人都能验证将军签名的真伪。

总结：
通过三国杀角色来讲解分布式中共识场景。那他们和分布式系统的映射关系是怎么样的呢？

1 将军对应计算机节点。
2 忠臣的将军对应正常运行的计算机节点。
3 叛变的将军对应出现故障并会发送误导信息的计算机节点。
4 信使被杀对应通讯故障、信息丢失。
5 信使被间谍替换对应为通讯被恶意攻击、伪造信息或劫持通讯。

可不要小瞧拜占庭问题，它可是分布式场景最复杂的的故障场景。比如在数字货币的区块链技术中就有用到这些知识点。而且必须使用拜占庭容错算法（也就是 Byzantine Fault Tolerance，BFT）。

拜占庭容错算法还有 FBFT 算法，PoW 算法，当然不会在这篇中去讲这些算法，后续再讲解。一口吃不了大胖子~

Paxos 算法

Paxos 是分布式算法中的老大哥，可以说 Paxos 是分布式共识的代名词。最常用的分布式共识算法都是基于它改进。比如 Raft 算法（后面也会介绍）。所以学习分布式算法必须先学习 Paxos 算法。

Paxos 算法主要包含两个部分：
1 Basic Paxos 算法：多个节点之间如何就某个值达成共识。（这个值我们称作提案 Value）
2 Multi-Paxos 算法：执行多个 Basic Paxos 实例，就一系列值达成共识。

Basic Paxos 算法是 Multi-Paxos 思想的核心，Multi 的意思就是多次，也就是说多执行几次 Basic Paxos 算法。所以 Basic Paxos 算法是重中之重。

角色：
Paxos 中有三种角色：提议者、接受者、学习者。

提议者（Proposer）
提议一个值，用于投票表决。
接入和协调，收到客户端的请求后，可以发起二阶段提交，进行共识协商。

映射到上面的故事中，军师就是用来部署作战计划的。

接受者（Acceptor）
对每个提议的值进行投票，并存储接受的值。
投票协商和存储数据，对提议的值进行投票，并接受达成共识的值，存储保存。
映射到上面的故事中，武将就是用来接受军师的作战计划。

其实，集群中所有的节点都在扮演接受者的角色，参与共识协商，并接受和存储数据。

学习者（Learner）
被告知投票的结果，接受达成共识的值，存储数据，
不参与投票的过程，即不参与共识协商。

映射到上面的故事中，就是两名文臣作为记录作战方案的备胎。

一个节点 可以有多个 角色
接受者 or 提议者
为什么说节点可以扮演接受者，也可以扮演提议者呢？

上篇我在讲解 BASE 协议的时候，讲到二阶段提交协议。其中有一个协调者的身份，协调者既可以是接受者，也可以是提议者。
1 作为接受者，接收客户端的消息。比如诸葛亮需要接收刘备的作战要求。
2 作为提议者，发起二阶段提交。然后这个节点和另外其他节点作为接受者进行共识协商。比如诸葛亮要汇总最终的作战计划给刘备。

具体传输方法 参考 如下 文章：
https://mp.weixin.qq.com/s/NATnrFn47TGLLlOivqm_PQ

总结：
Basic Paxos 也是通过二阶段提交协议达成共识。准备阶段、接受阶段。不知道二阶段提交协议的，可以看我前面的文章。《用太极拳讲分布式理论，舒服！》

Basic Paxos 不仅仅实现了共识，还实现了容错。有少于一半的节点出现故障时，集群也能正常工作。文中也多次强调了大多数节点都同意的原则，而这个原则赋予了 Basic Paxos 容错的能力。

提案编号代表优先级，保证了三个承诺：

1 如果准备请求的提案编号，小于等于接受者已经响应的准备请求的提案编号，那么接受者将承诺不响应这个准备请求。
2 如果接受请求中的提案的提案编号，小于接受者已经响应的准备请求的提案，那么接受者将承诺不通过这个提案。
3 如果接受者之前有通过提案，那么接受者将承诺，会在准备请求的响应中，包含已经通过的最大编号的提案信息。

Raft 协议

Raft协议对标Paxos，容错性和性能都是一致的，但是Raft比Paxos更易理解和实施。系统分为几种角色：
1 Leader（发出提案）
2 Follower（参与决策）
3 Candidate（Leader选举中的临时角色）

刚开始所有节点都是Follower状态，然后进行Leader选举
成功后Leader接受所有客户端的请求，然后把日志entry发送给所有Follower，当收到过半的节点的回复（而不是全部节点）时就给客户端返回成功并把commitIndex设置为该entry的index，所以是满足最终一致性的

Leader同时还会周期性地发送心跳给所有的Follower（会通过心跳同步提交的序号commitIndex），
Follower收到后就保持Follower状态（并应用commitIndex及其之前对应的日志entry），**如果Follower等待心跳超时了，则开始新的Leader选举：**首先把当前term计数加1，自己成为Candidate，然后给自己投票并向其它结点发投票请求。

直到以下三种情况：

1 它赢得选举；
2 另一个节点成为Leader；
3 一段时间没有节点成为Leader。

在选举期间，Candidate可能收到来自其它自称为Leader的写请求，如果该Leader的term不小于Candidate的当前term，那么Candidate承认它是一个合法的Leader并回到Follower状态，否则拒绝请求。

如果出现两个Candidate得票一样多，则它们都无法获取超过半数投票，这种情况会持续到超时，然后进行新一轮的选举，这时同时的概率就很低了，那么首先发出投票请求的的Candidate就会得到大多数同意，成为Leader。

在Raft协议出来之前，Paxos是分布式领域的事实标准，但是Raft的出现打破了这一个现状（raft作者也是这么想的，请看论文），Raft协议把Leader选举、日志复制、安全性等功能分离并模块化，使其更易理解和工程实现，将来发展怎样我们拭目以待（挺看好）。

Raft协议目前被用于 cockrouchDB，TiKV等项目中，据我听的一些报告来看，一些大厂自己造的分布式数据库也在使用Raft协议。

Gossip协议

Gossip协议与上述所有协议最大的区别就是它是去中心化的，上面所有的协议都有一个类似于Leader的角色来统筹安排事务的响应、提交与中断，但是Gossip协议中就没有Leader，每个节点都是平等的。

每个节点存放了一个key,value,version构成的列表，每隔一定的时间，节点都会主动挑选一个在线节点进行上图的过程（不在线的也会挑一个尝试），两个节点各自修改自己较为落后的数据，最终数据达成一致并且都较新。节点加入或退出都很容易。·

去中心化的Gossip看起来很美好：没有单点故障，看似无上限的对外服务能力……本来随着Cassandra火了一把，但是现在Cassandra也被抛弃了，去中心化的架构貌似难以真正应用起来。归根到底我觉得还是因为去中心化本身管理太复杂，节点之间沟通成本高，最终一致等待时间较长……

往更高处看，一个企业（甚至整个社会）不也是需要中心化的领导（或者制度）来管理吗，如果没有领导（或者制度）管理，大家就是一盘散沙，难成大事啊。

现代 互联网 架构，只要把 单点做的足够大，再加上若干个强一致的热备，一般问题都不大
事实上现代互联网架构只要把单点做得足够强大，再加上若干个强一致的热备，一般问题都不大。