分布式协议笔记

Paxos由Lamport于1998年在《The Part-Time Parliament》论文中首次公开，最初的描述使用希腊的一个小岛Paxos作为比喻，描述了Paxos小岛中通过决议的流程，并以此命名这个算法，但是这个描述理解起来比较有挑战性。后来在2001年，Lamport觉得同行不能理解他的幽默感，于是重新发表了朴实的算法描述版本《Paxos Made Simple》。

自Paxos问世以来就持续垄断了分布式一致性算法，Paxos这个名词几乎等同于分布式一致性。Google的很多大型分布式系统都采用了Paxos算法来解决分布式一致性问题，如Chubby、Megastore以及Spanner等。开源的ZooKeeper，以及MySQL 5.7推出的用来取代传统的主从复制的MySQL Group Replication等纷纷采用Paxos算法解决分布式一致性问题。

然而，Paxos的最大特点就是难，不仅难以理解，更难以实现。

二、Paxos算法流程

Paxos算法解决的问题正是分布式一致性问题，即一个分布式系统中的各个进程如何就某个值（决议）达成一致。

Paxos算法运行在允许宕机故障的异步系统中，不要求可靠的消息传递，可容忍消息丢失、延迟、乱序以及重复。它利用大多数 (Majority) 机制保证了2F+1的容错能力，即2F+1个节点的系统最多允许F个节点同时出现故障。

一个或多个提议进程 (Proposer) 可以发起提案 (Proposal)，Paxos算法使所有提案中的某一个提案，在所有进程中达成一致。系统中的多数派同时认可该提案，即达成了一致。最多只针对一个确定的提案达成一致。

Paxos将系统中的角色分为提议者 (Proposer)，决策者 (Acceptor)，和最终决策学习者 (Learner):

Proposer: 提出提案 (Proposal)。Proposal信息包括提案编号 (Proposal ID) 和提议的值 (Value)。
Acceptor：参与决策，回应Proposers的提案。收到Proposal后可以接受提案，若Proposal获得多数Acceptors的接受，则称该Proposal被批准。
Learner：不参与决策，从Proposers/Acceptors学习最新达成一致的提案（Value）。

在多副本状态机中，每个副本同时具有Proposer、Acceptor、Learner三种角色。

Paxos算法通过一个决议分为两个阶段（Learn阶段之前决议已经形成）：

第一阶段：Prepare阶段。Proposer向Acceptors发出Prepare请求，Acceptors针对收到的Prepare请求进行Promise承诺。
第二阶段：Accept阶段。Proposer收到多数Acceptors承诺的Promise后，向Acceptors发出Propose请求，Acceptors针对收到的Propose请求进行Accept处理。
第三阶段：Learn阶段。Proposer在收到多数Acceptors的Accept之后，标志着本次Accept成功，决议形成，将形成的决议发送给所有Learners。

Paxos算法流程中的每条消息描述如下：

Prepare: Proposer生成全局唯一且递增的Proposal ID (可使用时间戳加Server ID)，向所有Acceptors发送Prepare请求，这里无需携带提案内容，只携带Proposal ID即可。
Promise: Acceptors收到Prepare请求后，做出"两个承诺，一个应答"。

两个承诺：

不再接受Proposal ID小于等于（注意：这里是<= ）当前请求的Prepare请求。
不再接受Proposal ID小于（注意：这里是< ）当前请求的Propose请求。

一个应答：

不违背以前作出的承诺下，回复已经Accept过的提案中Proposal ID最大的那个提案的Value和Proposal ID，没有则返回空值。

Propose: Proposer 收到多数Acceptors的Promise应答后，从应答中选择Proposal ID最大的提案的Value，作为本次要发起的提案。如果所有应答的提案Value均为空值，则可以自己随意决定提案Value。然后携带当前Proposal ID，向所有Acceptors发送Propose请求。
Accept: Acceptor收到Propose请求后，在不违背自己之前作出的承诺下，接受并持久化当前Proposal ID和提案Value。
Learn: Proposer收到多数Acceptors的Accept后，决议形成，将形成的决议发送给所有Learners。

Paxos算法伪代码描述如下：

获取一个Proposal ID n，为了保证Proposal ID唯一，可采用时间戳+Server ID生成；
Proposer向所有Acceptors广播Prepare(n)请求；
Acceptor比较n和minProposal，如果n>minProposal，minProposal=n，并且将 acceptedProposal 和 acceptedValue 返回；
Proposer接收到过半数回复后，如果发现有acceptedValue返回，将所有回复中acceptedProposal最大的acceptedValue作为本次提案的value，否则可以任意决定本次提案的value；
到这里可以进入第二阶段，广播Accept (n,value) 到所有节点；
Acceptor比较n和minProposal，如果n>=minProposal，则acceptedProposal=minProposal=n，acceptedValue=value，本地持久化后，返回；否则，返回minProposal。
提议者接收到过半数请求后，如果发现有返回值result >n，表示有更新的提议，跳转到1；否则value达成一致。

下面举几个例子，实例1如下图：

Paxos算法实例1

图中P代表Prepare阶段，A代表Accept阶段。3.1代表Proposal ID为3.1，其中3为时间戳，1为Server ID。X和Y代表提议Value。

实例1中P 3.1达成多数派，其Value(X)被Accept，然后P 4.5学习到Value(X)，并Accept。

Paxos算法实例2

实例2中P 3.1没有被多数派Accept（只有S3 Accept），但是被P 4.5学习到，P 4.5将自己的Value由Y替换为X，Accept（X）。

Paxos算法实例3

实例3中P 3.1没有被多数派Accept（只有S1 Accept），同时也没有被P 4.5学习到。由于P 4.5 Propose的所有应答，均未返回Value，则P 4.5可以Accept自己的Value (Y)。后续P 3.1的Accept (X) 会失败，已经Accept的S1，会被覆盖。

Paxos算法可能形成活锁而永远不会结束，如下图实例所示：

回顾两个承诺之一，Acceptor不再应答Proposal ID小于等于当前请求的Prepare请求。意味着需要应答Proposal ID大于当前请求的Prepare请求。

两个Proposers交替Prepare成功，而Accept失败，形成活锁（Livelock）。

三、Multi-Paxos算法

原始的Paxos算法（Basic Paxos）只能对一个值形成决议，决议的形成至少需要两次网络来回，在高并发情况下可能需要更多的网络来回，极端情况下甚至可能形成活锁。如果想连续确定多个值，Basic Paxos搞不定了。因此Basic Paxos几乎只是用来做理论研究，并不直接应用在实际工程中。

实际应用中几乎都需要连续确定多个值，而且希望能有更高的效率。Multi-Paxos正是为解决此问题而提出。Multi-Paxos基于Basic Paxos做了两点改进：

针对每一个要确定的值，运行一次Paxos算法实例（Instance），形成决议。每一个Paxos实例使用唯一的Instance ID标识。
在所有Proposers中选举一个Leader，由Leader唯一地提交Proposal给Acceptors进行表决。这样没有Proposer竞争，解决了活锁问题。在系统中仅有一个Leader进行Value提交的情况下，Prepare阶段就可以跳过，从而将两阶段变为一阶段，提高效率。

Multi-Paxos首先需要选举Leader，Leader的确定也是一次决议的形成，所以可执行一次Basic Paxos实例来选举出一个Leader。选出Leader之后只能由Leader提交Proposal，在Leader宕机之后服务临时不可用，需要重新选举Leader继续服务。在系统中仅有一个Leader进行Proposal提交的情况下，Prepare阶段可以跳过。

Multi-Paxos通过改变Prepare阶段的作用范围至后面Leader提交的所有实例，从而使得Leader的连续提交只需要执行一次Prepare阶段，后续只需要执行Accept阶段，将两阶段变为一阶段，提高了效率。为了区分连续提交的多个实例，每个实例使用一个Instance ID标识，Instance ID由Leader本地递增生成即可。

Multi-Paxos允许有多个自认为是Leader的节点并发提交Proposal而不影响其安全性，这样的场景即退化为Basic Paxos。

Chubby和Boxwood均使用Multi-Paxos。ZooKeeper使用的Zab也是Multi-Paxos的变形。

附Paxos算法推导过程

Paxos算法的设计过程就是从正确性开始的，对于分布式一致性问题，很多进程提出（Propose）不同的值，共识算法保证最终只有其中一个值被选定，Safety表述如下：

只有被提出（Propose）的值才可能被最终选定（Chosen）。
只有一个值会被选定（Chosen）。
进程只会获知到已经确认被选定（Chosen）的值。

Paxos以这几条约束作为出发点进行设计，只要算法最终满足这几点，正确性就不需要证明了。Paxos算法中共分为三种参与者：Proposer、Acceptor以及Learner，通常实现中每个进程都同时扮演这三个角色。

Proposers向Acceptors提出Proposal，为了保证最多只有一个值被选定（Chosen），Proposal必须被超过一半的Acceptors所接受（Accept），且每个Acceptor只能接受一个值。

为了保证正常运行（必须有值被接受），所以Paxos算法中：

P1：Acceptor必须接受（Accept）它所收到的第一个Proposal。

先来先服务，合情合理。但这样产生一个问题，如果多个Proposers同时提出Proposal，很可能会导致无法达成一致，因为没有Propopal被超过一半Acceptors的接受，因此，Acceptor必须能够接受多个Proposal，不同的Proposal由不同的编号进行区分，当某个Proposal被超过一半的Acceptors接受后，这个Proposal就被选定了。

既然允许Acceptors接受多个Proposal就有可能出现多个不同值都被最终选定的情况，这违背了Safety要求，为了保证Safety要求，Paxos进一步提出：

P2：如果值为v的Proposal被选定（Chosen），则任何被选定（Chosen）的具有更高编号的Proposal值也一定为v。

只要算法同时满足P1和P2，就保证了Safety。P2是一个比较宽泛的约定，完全没有算法细节，我们对其进一步延伸：

P2a：如果值为v的Proposal被选定（Chosen），则对所有的Acceptors，它们接受（Accept）的任何具有更高编号的Proposal值也一定为v。

如果满足P2a则一定满足P2，显然，因为只有首先被接受才有可能被最终选定。但是P2a依然难以实现，因为acceptor很有可能并不知道之前被选定的Proposal（恰好不在接受它的多数派中），因此进一步延伸：

P2b：如果值为v的Proposal被选定（Chosen），则对所有的Proposer，它们提出的的任何具有更高编号的Proposal值也一定为v。

更进一步的：

P2c：为了提出值为v且编号为n的Proposal，必须存在一个包含超过一半Acceptors的集合S，满足(1) 没有任何S中的Acceptors曾经接受（Accept）过编号比n小的Proposal，或者(2) v和S中的Acceptors所接受过(Accept)的编号最大且小于n的Proposal值一致。

满足P2c即满足P2b即满足P2a即满足P2。至此Paxos提出了Proposer的执行流程，以满足P2c：

Proposer选择一个新的编号n，向超过一半的Acceptors发送请求消息，Acceptor回复: (a)承诺不会接受编号比n小的proposal，以及(b)它所接受过的编号比n小的最大Proposal（如果有）。该请求称为Prepare请求。

如果Proposer收到超过一半Acceptors的回复，它就可以提出Proposal，Proposal的值为收到回复中编号最大的Proposal的值，如果没有这样的值，则可以自由提出任何值。

向收到回复的Acceptors发送Accept请求，请求对方接受提出的Proposal。

仔细品味Proposer的执行流程，其完全吻合P2c中的要求，但你可能也发现了，当多个Proposer同时运行时，有可能出现没有任何Proposal可以成功被接受的情况（编号递增的交替完成第一步），这就是Paxos算法的Liveness问题，或者叫"活锁"，论文中建议通过对Proposers引入选主算法选出Distinguished Proposer来全权负责提出Proposal来解决这个问题，但是即使在出现多个Proposers同时提出Proposal的情况时，Paxos算法也可以保证Safety。

接下来看看Acceptors的执行过程，和我们对P2做的事情一样，我们对P1进行延伸：

P1a：Acceptor可以接受（Accept）编号为n的Proposal当且仅当它没有回复过一个具有更大编号的Prepare消息。

易见，P1a包含了P1，对于Acceptors：

当收到Prepare请求时，如果其编号n大于之前所收到的Prepare消息，则回复。

当收到Accept请求时，仅当它没有回复过一个具有更大编号的Prepare消息，接受该Proposal并回复。

以上涵盖了满足P1a和P2b的一套完整一致性算法。

raft

说明：Paxos算法不容易实现，Raft算法是对Paxos算法的简化和改进

概念介绍

Leader总统节点，负责发出提案
Follower追随者节点，负责同意Leader发出的提案
Candidate候选人，负责争夺Leader

算法步骤

步骤：Raft算法将一致性问题分解为两个的子问题，Leader选举和状态复制

Leader选举

1.每个Follower都持有一个定时器

2.当定时器时间到了而集群中仍然没有Leader，Follower将声明自己是Candidate并参与Leader选举，同时将消息发给其他节点来争取他们的投票，若其他节点长时间没有响应Candidate将重新发送选举信息

集群中其他节点将给Candidate投票
获得多数派支持的Candidate将成为第M任Leader（M任是最新的任期）
在任期内的Leader会不断发送心跳给其他节点证明自己还活着，其他节点受到心跳以后就清空自己的计时器并回复Leader的心跳。这个机制保证其他节点不会在Leader任期内参加Leader选举。

当Leader节点出现故障而导致Leader失联，没有接收到心跳的Follower节点将准备成为Candidate进入下一轮Leader选举
若出现两个Candidate同时选举并获得了相同的票数，那么这两个Candidate将随机推迟一段时间后再向其他节点发出投票请求，这保证了再次发送投票请求以后不冲突

状态复制

Leader负责接收来自Client的提案请求（红色提案表示未确认）
提案内容将包含在Leader发出的下一个心跳中
Follower接收到心跳以后回复Leader的心跳
Leader接收到多数派Follower的回复以后确认提案并写入自己的存储空间中并回复Client
Leader通知Follower节点确认提案并写入自己的存储空间，随后所有的节点都拥有相同的数据
若集群中出现网络异常，导致集群被分割，将出现多个Leader
被分割出的非多数派集群将无法达到共识，即脑裂，如图中的A、B节点将无法确认提案
当集群再次连通时，将只听从最新任期Leader的指挥，旧Leader将退化为Follower，如图中B节点的Leader（任期1）需要听从D节点的Leader（任期2）的指挥，此时集群重新达到一致性状态

zab算法

说明：ZAB也是对Multi Paxos算法的改进，大部分和raft相同

和raft算法的主要区别：

对于Leader的任期，raft叫做term，而ZAB叫做epoch

在状态复制的过程中，raft的心跳从Leader向Follower发送，而ZAB则相反。

一致性哈希算法

一致性Hash算法也是使用取模的方法，普通的取模法是对服务器的数量进行取模，而一致性Hash算法是对232取模，什么意思呢？简单来说，一致性Hash算法将整个哈希值空间组织成一个虚拟的圆环，如假设某哈希函数H的值空间为0-232-1（即哈希值是一个32位无符号整形），整个哈希环如下：

整个空间按顺时针方向组织，圆环的正上方的点代表0，0点右侧的第一个点代表1，以此类推，2、3、4、5、6......直到232-1，也就是说0点左侧的第一个点代表232-1， 0和232-1在零点中方向重合，我们把这个由232个点组成的圆环称为Hash环。

下一步将各个服务器使用Hash进行一个哈希，具体可以选择服务器的IP或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置，这里假设将上文中四台服务器使用IP地址哈希后在环空间的位置如下：

接下来使用如下算法定位数据访问到相应服务器：将数据key使用相同的函数Hash计算出哈希值，并确定此数据在环上的位置，从此位置沿环顺时针"行走"，第一台遇到的服务器就是其应该定位到的服务器！

例如我们有Object A、Object B、Object C、Object D四个数据对象，经过哈希计算后，在环空间上的位置如下：

根据一致性Hash算法，数据A会被定为到Node A上，B被定为到Node B上，C被定为到Node C上，D被定为到Node D上。

一致性Hash算法的容错性和可扩展性

现假设Node C不幸宕机，可以看到此时对象A、B、D不会受到影响，只有C对象被重定位到Node D。一般的，在一致性Hash算法中，如果一台服务器不可用，则受影响的数据仅仅是此服务器到其环空间中前一台服务器（即沿着逆时针方向行走遇到的第一台服务器）之间数据，其它不会受到影响，如下所示：

下面考虑另外一种情况，如果在系统中增加一台服务器Node X，如下图所示：

此时对象Object A、B、D不受影响，只有对象C需要重定位到新的Node X ！一般的，在一致性Hash算法中，如果增加一台服务器，则受影响的数据仅仅是新服务器到其环空间中前一台服务器（即沿着逆时针方向行走遇到的第一台服务器）之间数据，其它数据也不会受到影响。

综上所述，一致性Hash算法对于节点的增减都只需重定位环空间中的一小部分数据，具有较好的容错性和可扩展性。

Hash环的数据倾斜问题

一致性Hash算法在服务节点太少时，容易因为节点分部不均匀而造成数据倾斜（被缓存的对象大部分集中缓存在某一台服务器上）问题，例如系统中只有两台服务器，其环分布如下：

此时必然造成大量数据集中到Node A上，而只有极少量会定位到Node B上。为了解决这种数据倾斜问题，一致性Hash算法引入了虚拟节点机制，即对每一个服务节点计算多个哈希，每个计算结果位置都放置一个此服务节点，称为虚拟节点。具体做法可以在服务器IP或主机名的后面增加编号来实现。

例如上面的情况，可以为每台服务器计算三个虚拟节点，于是可以分别计算 "Node A#1"、"Node A#2"、"Node A#3"、"Node B#1"、"Node B#2"、"Node B#3"的哈希值，于是形成六个虚拟节点

区块链中的共识算法

简单的区块链逻辑

联盟链为例。联盟间预先设定好符合业务场景需要的数据库表结构，然后设定好各个节点对表的操作权限（ADD，UPDATE，DELETE），将来各个节点就可以按照自己被允许的权限，进行Sql语句的编写，并打包至Block中，再全网广播，等待全网校验签名、权限等信息的合法性。如果Block合法，则进入PBFT共识算法机制，各节点开始按照PrePrepare、Prepare、Commit等状态依次执行，直到2f+1个commit后，开始进行本地生成新区块。新区块生成后，各节点进行区块内容解析，并落地入库的操作。

区块链的几种类型

公链------人人可参与

公链是指任何人都可读取的、任何人都能发送交易且交易能获得有效确认的、任何人都能参与其中共识过程的区块链。

公链采取了采取工作量证明机制（POW）、权益证明机制(POS)、股份授权证明机制（DPOS）等方式，并将经济奖励和加密数字验证结合了起来，并建立一个原则就是每个人从中可获得的经济奖励与工作量成正比。这些区块链通常被认为是完全去中心化的。

特性：

开源

由于整个系统的运作规则公开透明，这个系统是开源系统；

保护用户免受开发者的影响

在公有链中程序开发者无权干涉用户，所以区块链可以保护使用他们开发的程序的用户;

3.访问门槛低

任何拥有足够技术能力的人都可以访问，也就是说，只要有一台能够联网的计算机就能够满足访问的条件;

4.所有数据默认公开

尽管所有关联的参与者都隐藏自己的真实身份，这种现象十分的普遍。他们通过他们的公共性来产生自己的安全性，在这里每个参与者可以看到所有的账户余额和其所有的交易活动。

案例：公有链中有许多我们熟悉的身影：BTC, ETH, EOS, AE, ADA等

私链------权利掌握在少数人手里

私链是指其写入权限仅在一个组织手里的区块链。读取权限或者对外开放，或者被任意程度地进行了限制。相关的应用囊括数据库管理、审计、甚至一个公司，尽管在有些情况下希望它能有公共的可审计性，但在很多的情形下，公共的可读性并非是必须的。

特性：

1.交易速度快

一个私链的交易速度可以比任何其他的区块链都快，甚至接近了并不是一个区块链的常规数据库的速度。这是因为就算少量的节点也都具有很高的信任度，并不需要每个节点来验证一个交易。

2.隐私性好

给隐私更好的保障私有链使得在那个区块链上的数据隐私政策像在另一个数据库中似的完全一致;不用处理访问权限和使用所有的老办法，但至少说，这个数据不会公开地被拥有网络连接的任何人获得。

3.交易成本低

交易成本大幅降低甚至为零私有链上可以进行完全免费或者至少说是非常廉价的交易。如果一个实体机构控制和处理所有的交易，那么他们就不再需要为工作而收取费用。

案例：Linux基金会、R3CEV Corda平台以及Gem Health网络的超级账本项目（Hyperledger project）或在开发或在使用私链。

联盟链------部分去中心化

联盟链开放程度和去中心化程度是有所限制的。其参与者是被提前筛选出来或者直接指定的，数据库的读取权限可能是公开的，也可能像写入权限一样只限于系统的参与者。

特性：

1.交易成本低

交易只需被几个受信的高算力节点验证就可以了，而无需全网确认；

2.节点容易连接

若是出了问题，联盟链可以迅速通过人工干预来修复，并允许使用共识算法减少区块时间，从而更快完成交易；

3.灵活

如果需要的话，运行私有区块链的共同体或公司可以很容易地修改该区块链的规则，还原交易，修改余额等。

案例：瑞波用于日韩国际汇款及日本本国银行间汇款建立了联盟链，同时之前火过一阵子的迅雷链克也是一种半开放的联盟链。

侧链------拓展协议

侧链"从严格上来说，其本身并不是区块链，可以理解为区块链的一种扩展协议。早期"侧链"是为了解决比特币区块链技术的限制问题。侧链就像是一条条通路，将不同的区块链互相连接在一起，以实现区块链的扩展。侧链完全独立于比特币区块链，但是这两个账本之间能够"互相操作"，实现交互。

特性：

1.独立性

侧链架构的好处是代码和数据独立，不增加主链的负担，避免数据过度膨胀。侧链有独立的区块链，有独立的受托人或者说见证人，同时也有独立的节点网络，就是说一个侧链产生的区块只会在所有安装了该侧链的节点之间进行广播。

2.灵活性

侧链所有的区块链参数是可以定制的，简单的比如区块间隔、区块奖励、交易费的去向等，高级用户还可以修改共识算法。

案例：LSK, RDN, ARDR等币种是利用的侧链技术。

RPC协议

基于HTTP的RPC

基于TCP的RPC

语言/RPC框架	Dubbo	rpcx	gRPC	Thrift
开发语言	Java	Go	跨语言	跨语言
分布式(服务治理)	支持	支持	不支持，需要封装	不支持
多序列化框架支持	支持	支持	只支持protobuf	只支持thrift格式

Thrift 协议

数据传输协议

1.TBinaryProtocol : 二进制格式.

2.TCompactProtocol : 压缩格式

3.TJSONProtocol : JSON格式

4.TSimpleJSONProtocol : 提供JSON只写协议, 生成的文件很容易通过脚本语言解析

服务端

1.实现服务处理接口impl

2.创建TProcessor

3.创建TServerTransport

4.创建TProtocol

5.创建TServer

6.启动Server

客户端

1.创建Transport

2.创建TProtocol

3.基于TTransport和TProtocol创建 Client

4.调用Client的相应方法

Protocol Buffer

Protocol Buffers 是一种轻便高效的结构化数据存储格式，可以用于结构化数据序列化，很适合做数据存储或 RPC 数据交换格式。它可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。

限定修饰符

require

表示这个字段不为空

optional

表示这个字段是可选的，可以有1个或者0个值

repeated

表示这个字段可以多次，0~n次，相当于List

Protocol Buffer与Json对比

Thrift适用于程序对程序静态的数据交换

Protocol Buffer 的序列化 & 反序列化简单 & 速度快的原因是：

编码 / 解码方式简单（只需要简单的数学运算 = 位移等等）
采用 Protocol Buffer 自身的框架代码和编译器共同完成

Protocol Buffer 的数据压缩效果好（即序列化后的数据量体积小）的原因是：

采用了独特的编码方式，如 Varint、Zigzag 编码方式等等
采用 T - L - V 的数据存储方式：减少了分隔符的使用 & 数据存储得紧凑

Nginx

负载均衡策略：

轮询	默认方式
weight	权重方式
ip_hash	依据ip分配方式
least_conn	最少连接方式
fair（第三方）	响应时间方式
url_hash（第三方）	依据URL分配方式