ZooKeeper理论基础

看书时的一些笔记，非原创，转到csdn当做备份了，本地笔记维护不动了

很多图是在typora中用mermaid画的，有源码

共识算法：拜占庭将军问题(The Byzantine Generals Problem)

提供了对分布式共识问题的一种情景化描述，由Leslie Lamport等人在1982年首次发表。论文《The Byzantine Generals Problem 》同时提供了两种解决拜占庭将军问题的算法：

• 口信消息型解决方案(A solution with oral message)
• 签名消息型解决方案(A solution with signed message)

拜占庭将军问题是分布式系统领域最复杂的容错模型， 它描述了如何在存在恶意行为(如消息篡改或伪造)的情况下使分布式系统达成一致。

ABC三个将军的军队驻扎在敌城外，每名将军通过信使进行沟通以决定共同的行动计划：进攻（Attack）或撤退（Retreat），只有当半数以上将军共同发起进攻时才能取得胜利。但将军甚至信使中都可能出现叛徒，试图阻止忠诚的将军达成一致的行动计划。

以简单的3将军场景为例

正常状态下，三位将军通过观察敌情得出进攻和撤退的计划，在少数服从多数的情况下，下图最终 attck:retreat = 2:1 决定发起总攻。

当将军中出现叛徒时，会诱导另外两个将军一个发起进攻，一个撤退，导致一个将军陷入险境。下图中演示了叛徒C（也可能信使是叛徒）分别通知A决定进攻，通知B决定撤退，而此时AB意见相左，导致A看来 attack:retreat=2:1，B看来 attack:retreat=1:2，最终只有A发起了进攻。

Leslie Lamport的论文中证明出这种场景下达到一致的行动方案是不可能的，并给出了一个结论：如果存在m个叛将，那么至少需要3m+1个将军才能达到一致的行动方案。

口信消息型解决方案

三位副官由一个commander统领。

对于口信消息的定义：A1. 任何已经发送的消息都将被正确传达;A2. 消息的接收者知道是谁发送了消息;A3. 消息的缺席可以被检测。

口信信息不能被篡改但可以被伪造，当存在1个叛将时，需要再增加3个忠将才能达到最终的一致行动。

指挥官发出进攻的消息，在第二轮中，3位副官进行作战信息协商，C作为叛将发出retreat，但最终仍能达成一致的attack。

在指挥官为叛将，副官均为忠将的场景下，指挥官仅向C发出了retreat指令。但在第二轮的信息同步中，所有忠将都能达成一致的撤退计划

对于口信消息型拜占庭将军问题，如果叛将人数为m，将军人数不少于3m+1，那么最终能达成一致的行动计划。值的注意的是，在这个算法中，叛将人数m是已知的，且叛将人数m决定了递归的次数，即叛将数m决定了进行作战信息协商的轮数，如果存在m个叛将，则需要进行m+1轮作战信息协商。

签名消息型解决方案

签名消息的定义是在口信消息定义的基础上增加了如下两条：A4. 忠诚将军的签名无法伪造，而且对他签名消息的内容进行任何更改都会被发现；A5. 任何人都能验证将军签名的真伪。

签名消息无法被伪造或者篡改，如上述的3将军问题，C企图篡改A的attck消息，但B能够发现，转而执行A的attack指令

签名消息型解决方案可以处理任何数量叛将的场景。

ZAB算法陈述（P73）

​
Paxos算法
Paxos协议 引入大多数/过半的少数服从多数的原则

支持分布式节点间的角色轮换，避免了分布式单点问题的出现，解决了无限期等待、脑裂问题

Paxos算法是Leslie Lamport与1990年提出的一种基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题的最有效算法之一。

【历史】Lamport于1990年借希腊民主议会的比喻进行介绍Paxos算法，但未获得理解。后人不断对Paxos算法进行讲解（Raft算法作者Diego Ongaro）

Paxos小岛议会问题（The Part-Time Parliament.Leslie）- Revisiting the Paxos Algorithm.Nancy Lynch - Paxos Made Simple.Leslie Lamport

算法涉及的角色有：Proposer - 提案发起者、Acceptor - 提案接受者、Learner - 从Acceptor同步最新提案

技术背景
采用master节点写，同步到多个slave节点进行读的设计容易因master节点宕机造成单点故障，为了克服单点写入问题，提出了多数派（quorum）写，即写入一半以上节点：如果集群中有N个节点，客户端需要写入 W>=N/2+1 个节点，不需要主节点，这种方案可以容忍最多 (N-1)/2 个节点故障。

提案编号的设计：简单的方式就是每个请求一个唯一编号 <seq_id, server_id>，seq_id是自增的，同时为了崩溃恢复，需要在本地持久化存储

Paxos算法陈述
这是一个类似两阶段提交的算法执行过程，第一阶段 - 准备 Prepare 阶段，第二阶段 - 接收 Accept 阶段，分别对应两轮RPC

提案的选定

Learner获取提案

Paxos算法推导过程
在没有失败和消息丢失的情况下，如果希望即使在只有一个提案被提出的情况下，仍然可以选出一个提案，就需要：

P1会遇到下述问题场景：如果多个提案同时被不同Proposer提出，对应的多个Acceptor又批准了它收到的第一个提案，这样会导致没有一个提案是由多数人都批准的；如果5个Acceptor中2个Acceptor接受了一个提案1，而另外3个接受提案2时有一个发生了故障，这样就无法确定出一个被多数Acceptor采用的提案；

所以需要增加限制条件：

P2会遇到下述问题场景：提案(M(1),V(1))可能被P1提出来并很快被多数Acceptor采纳，而如果此时有一个Acceptor未收到这个提案，并且恰好采纳了P2提出的(M(2),V(2))，M(2)>M(1)

此时需要强化：

因为任何包含半数以上Acceptor的集合S都至少包含半数以上Acceptor组成的集合C中的一员，因此保证P2b成立可以通过下述条件达成：

a. Proposer选择一个新的提案编号M(n)，然后向某个Acceptor集合的成员发送请求，要求该集合中的Acceptor作出如下回应：

向Proposer承诺不再批准任何编号小于M(n)的提案

如果Acceptor已经批准任何提案，那么其就向Proposer反馈当前该Acceptor已经批准的编号小于M(n)的最大编号的提案的Value

b. 如果Proposer收到了来自半数以上Acceptor的响应结果，那么它就可以产生提案(M(n),V(n))，V(n)是所有响应中编号最大的提案的值。还存在另外一种特殊情况，就是半数以上的Acceptor都没有批准过任何提案，即响应中不包含任何提案，此时V(n)就可以由Proposer任意选择。

在确定提案之后，Proposer就会将该提案再次发送给某个Acceptor集合，并期望获得采纳，此请求就是Accept请求。需要注意的是 Accept阶段接受Accept请求的Acceptor集合不一定是之前响应Prepare请求的Acceptor集合，因为任意半数以上（大多数）的Acceptor集合必定包含至少一个公共Acceptor

a阶段实际就是Prepare阶段，b阶段对应的就是Accept阶段

Acceptor会收到Proposer的两种请求：Prepare请求和Accept请求，一个Acceptor只要尚未响应过任何编号大于M(n)的Prepare请求，那么它就可以接受这个编号为M(n)的提案。否则Acceptor在已经对编号大于M(n)的Prepare请求作出相应的情况下，会忽略任何编号为M(n)的提案。另外，Acceptor可以忽略掉其已经批准过的提案的Prepare请求。

综上，Acceptor可以记住它已经批准的提案的最大编号以及已经做出Prepare请求响应的提案的最大编号，以防止发生故障和节点重启时的数据丢失

通过选取主Proposer保证算法活性：存在一种特殊情况会导致算法死循环，当存在两个Proposer P1 P2时，P1提出编号M1的提案在Prepare阶段被采纳，但与此同时P2提出了编号为M2(M2>M1)的提案完成了Prepare阶段。此后P1在Accept阶段的请求因为编号小会被忽略，P1转而进入Prepare阶段提出编号为P3的提案，这又导致P2在Accept阶段的请求被忽略，最终导致死循环（活锁现象）。解决办法是：引入随机超时让某个Proposer先进行提案 / 选择出一个主Proposer，并规定只有主Proposer才能提出议案。

Paxos协议的工程应用
Chubby是Google的分布式锁服务，在GFS和Big Table中有应用。谷歌官方论文

Hypertable是一个开源、高性能、可伸缩的数据库，支持对大量并发请求的处理，支持海量数据的管理，扩展性良好，在保证可用性前提下，可以随意添加集群中的机器来实现水平扩容；有着非常好的容错性，任何节点的失效既不会造成系统瘫痪也不会影响数据的完整性。核心组件包括Hyperspace、RangeServer、Master和DFS Broker四个部分

​