本篇文章主要给网友们分享区块链raft算法的知识，其中更加会对raft算法详解进行更多的解释，如果能碰巧解决你现在面临的问题，记得关注本站！
深入了解区块链的共识机制及算法原理
所谓“共识机制”，是通过特殊节点区块链raft算法的投票，在很短区块链raft算法的时间内完成对交易的验证和确认；对一笔交易，如果利益不相干的若干个节点能够达成共识，我们就可以认为全网对此也能够达成共识。再通俗一点来讲，如果中国一名微博大V、美国一名虚拟币玩家、一名非洲留学生和一名欧洲旅行者互不相识，但区块链raft算法他们都一致认为你是个好人，那么基本上就可以断定你这人还不坏。
要想整个区块链网络节点维持一份相同的数据，同时保证每个参与者的公平性，整个体系的所有参与者必须要有统一的协议，也就是我们这里要将的共识算法。比特币所有的节点都遵循统一的协议规范。协议规范（共识算法）由相关的共识规则组成，这些规则可以分为两个大的核心区块链raft算法：工作量证明与最长链机制。所有规则（共识）的最终体现就是比特币的最长链。共识算法的目的就是保证比特币不停地在最长链条上运转，从而保证整个记账系统的一致性和可靠性。
区块链中的用户进行交易时不需要考虑对方的信用、不需要信任对方，也无需一个可信的中介机构或中央机构，只需要依据区块链协议即可实现交易。这种不需要可信第三方中介就可以顺利交易的前提是区块链的共识机制，即在互不了解、信任的市场环境中，参与交易的各节点出于对自身利益考虑，没有任何违规作弊的动机、行为，因此各节点会主动自觉遵守预先设定的规则，来判断每一笔交易的真实性和可靠性，并将检验通过的记录写入到区块链中。各节点的利益各不相同，逻辑上将它们没有合谋欺骗作弊的动机产生，而当网络中有的节点拥有公共信誉时，这一点尤为明显。区块链技术运用基于数学原理的共识算法，在节点之间建立“信任”网络，利用技术手段从而实现一种创新式的信用网络。
目前区款连行业内主流的共识算法机制包含：工作量证明机制、权益证明机制、股份授权证明机制和Pool验证池这四大类。
工作量证明机制即对于工作量的证明，是生成要加入到区块链中的一笔新的交易信息(即新区块)时必须满足的要求。在基于工作量证明机制构建的区块链网络中，节点通过计算随机哈希散列的数值解争夺记账权，求得正确的数值解以生成区块的能力是节点算力的具体表现。工作量证明机制具有完全去中心化的优点，在以工作量证明机制为共识的区块链中，节点可以自由进出。大家所熟知的比特币网络就应用工作量证明机制来生产新的货币。然而，由于工作量证明机制在比特币网络中的应用已经吸引了全球计算机大部分的算力，其他想尝试使用该机制的区块链应用很难获得同样规模的算力来维持自身的安全。同时，基于工作量证明机制的挖矿行为还造成了大量的资源浪费，达成共识所需要的周期也较长，因此该机制并不适合商业应用。
2012年，化名Sunny King的网友推出了Peercoin，该加密电子货币采用工作量证明机制发行新币，采用权益证明机制维护网络安全，这是权益证明机制在加密电子货币中的首次应用。与要求证明人执行一定量的计算工作不同，权益证明要求证明人提供一定数量加密货币的所有权即可。权益证明机制的运作方式是，当创造一个新区块时，矿工需要创建一个“币权”交易，交易会按照预先设定的比例把一些币发送给矿工本身。权益证明机制根据每个节点拥有代币的比例和时间，依据算法等比例地降低节点的挖矿难度，从而加快了寻找随机数的速度。这种共识机制可以缩短达成共识所需的时间，但本质上仍然需要网络中的节点进行挖矿运算。因此，PoS机制并没有从根本上解决PoW机制难以应用于商业领域的问题。
股份授权证明机制是一种新的保障网络安全的共识机制。它在尝试解决传统的PoW机制和PoS机制问题的同时，还能通过实施科技式的民主抵消中心化所带来的负面效应。
股份授权证明机制与董事会投票类似，该机制拥有一个内置的实时股权人投票系统，就像系统随时都在召开一个永不散场的股东大会，所有股东都在这里投票决定公司决策。基于DPoS机制建立的区块链的去中心化依赖于一定数量的代表，而非全体用户。在这样的区块链中，全体节点投票选举出一定数量的节点代表，由他们来代理全体节点确认区块、维持系统有序运行。同时，区块链中的全体节点具有随时罢免和任命代表的权力。如果必要，全体节点可以通过投票让现任节点代表失去代表资格，重新选举新的代表，实现实时的民主。
股份授权证明机制可以大大缩小参与验证和记账节点的数量，从而达到秒级的共识验证。然而，该共识机制仍然不能完美解决区块链在商业中的应用问题，因为该共识机制无法摆脱对于代币的依赖，而在很多商业应用中并不需要代币的存在。
Pool验证池基于传统的分布式一致性技术建立，并辅之以数据验证机制，是目前区块链中广泛使用的一种共识机制。
Pool验证池不需要依赖代币就可以工作，在成熟的分布式一致性算法(Pasox、Raft)基础之上，可以实现秒级共识验证，更适合有多方参与的多中心商业模式。不过，Pool验证池也存在一些不足，例如该共识机制能够实现的分布式程度不如PoW机制等
这里主要讲解区块链工作量证明机制的一些算法原理以及比特币网络是如何证明自己的工作量的，希望大家能够对共识算法有一个基本的认识。
工作量证明系统的主要特征是客户端要做一定难度的工作来得到一个结果，验证方则很容易通过结果来检查客户端是不是做了相应的工作。这种方案的一个核心特征是不对称性：工作对于请求方是适中中的，对于验证方是易于验证的。它与验证码不同，验证码是易于被人类解决而不是易于被计算机解决。
下图所示的为工作量证明流程。
举个例子，给个一个基本的字符创“hello，world！”，我们给出的工作量要求是，可以在这个字符创后面添加一个叫做nonce（随机数）的整数值，对变更后（添加nonce）的字符创进行SHA-256运算，如果得到的结果（一十六进制的形式表示）以“0000”开头的，则验证通过。为了达到这个工作量证明的目标，需要不停地递增nonce值，对得到的字符创进行SHA-256哈希运算。按照这个规则，需要经过4251次运算，才能找到前导为4个0的哈希散列。
通过这个示例我们对工作量证明机制有了一个初步的理解。有人或许认为如果工作量证明只是这样一个过程，那是不是只要记住nonce为4521使计算能通过验证就行了，当然不是了，这只是一个例子。
下面我们将输入简单的变更为”Hello,World!+整数值”，整数值取1~1000，也就是说将输入变成一个1~1000的数组：Hello,World!1；Hello,World!2；...；Hello,World!1000。然后对数组中的每一个输入依次进行上面的工作量证明—找到前导为4个0的哈希散列。
由于哈希值伪随机的特性，根据概率论的相关知识容易计算出，预计要进行2的16次方次数的尝试，才能得到前导为4个0的哈希散列。而统计一下刚刚进行的1000次计算的实际结果会发现，进行计算的平均次数为66958次，十分接近2的16次方（65536）。在这个例子中，数学期望的计算次数实际就是要求的“工作量”，重复进行多次的工作量证明会是一个符合统计学规律的概率事件。
统计输入的字符创与得到对应目标结果实际使用的计算次数如下：
对于比特币网络中的任何节点，如果想生成一个新的区块加入到区块链中，则必须解决出比特币网络出的这道谜题。这道题的关键要素是工作量证明函数、区块及难度值。工作量证明函数是这道题的计算方法，区块是这道题的输入数据，难度值决定了解这道题的所需要的计算量。
比特币网络中使用的工作量证明函数正是上文提及的SHA-256。区块其实就是在工作量证明环节产生的。旷工通过不停地构造区块数据，检验每次计算出的结果是否满足要求的工作量，从而判断该区块是不是符合网络难度。区块头即比特币工作量证明函数的输入数据。
难度值是矿工们挖掘的重要参考指标，它决定了旷工需要经过多少次哈希运算才能产生一个合法的区块。比特币网络大约每10分钟生成一个区块，如果在不同的全网算力条件下，新区块的产生基本都保持这个速度，难度值必须根据全网算力的变化进行调整。总的原则即为无论挖矿能力如何，使得网络始终保持10分钟产生一个新区块。
难度值的调整是在每个完整节点中独立自动发生的。每隔2016个区块，所有节点都会按照统一的格式自动调整难度值，这个公式是由最新产生的2016个区块的花费时长与期望时长（按每10分钟产生一个取款，则期望时长为20160分钟）比较得出来的，根据实际时长一期望时长的比值进行调整。也就是说，如果区块产生的速度比10分钟快，则增加难度值；反正，则降低难度值。用公式来表达如下：
新难度值=旧难度值*（20160分钟/过去2016个区块花费时长）。
工作量证明需要有一个目标值。比特币工作量证明的目标值（Target）的计算公式如下：
目标值=最大目标值/难度值，其中最大目标值为一个恒定值0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
目标值的大小与难度值成反比，比特币工作量证明的达成就是矿中计算出来的区块哈希值必须小于目标值。
我们也可以将比特币工作量的过程简单的理解成，通过不停变更区块头（即尝试不同nonce值）并将其作为输入，进行SHA-256哈希运算，找出一个有特定格式哈希值的过程（即要求有一定数量的前导0），而要求的前导0个数越多，难度越大。
可以把比特币将这道工作量证明谜题的步骤大致归纳如下：
该过程可以用下图表示：
比特币的工作量证明，就是我们俗称“挖矿”所做的主要工作。理解工作量证明机制，将为我们进一步理解比特币区块链的共识机制奠定基础。
Paxos和Raft快速理解
Paxos问题指分布式系统中存在故障fault，但不存在恶意corrupt节点场景（消息可能丢失但不会造假）下的共识达成（Consensus）问题。
Paxos是第一个被证明的共识算法，原理基于两阶段提交并进行扩展。算法中将节点分为三种类型：
每个节点在协议中可以担任多个角色。
Paxos的特点：
假设5个节点构成分布式系统，A和E节点分别有X和Y提案，其他节点没有提案。
然后A节点广播它的提案，强假设网络延迟的原因，只有A，B，C节点收到提案，这里的提案哪怕A，E节点的提案同时到某个节点，也必然会有先后顺序的，是不可能真正意义上的同时。
A，B，C接收到A的提案后，由于是第一个接收到的提案，acceptedProposal和acceptedValue都为空，诚实返回。
由于A节点已经收到超半数的节点相应，且返回的acceptedValue都为空，也就是说可以用X作为提议的值来发生Accept请求，A，B，C节点接收到请求后，将acceptedValue更新为X。
A，B，C节点会发生minProposal给A，A检查发现没有大于1的minProposal出现，此时X已经被选中。此时，由于D，E节点的acceptedValue并不是X，系统还没有达成一致共识，Paxos过程还是没有结束。
E节点选择Proposal ID为2发送Prepare请求，结果和上面是一样的，因为C节点已经选择接受了A节点的提议，它是很诚实的，就直接告诉E节点他的选择，E节点知道C节点既然选择了A的提案，那自己也选A的提案。于是，E发起Accept请求，使用X作为提议值，至此，整个分布式系统达成了一致，大家都选择了X。
两个阶段分别是准备（prepare）和提交（commit）。准备阶段解决大家对哪个提案进行投票的问题，提交阶段解决确认最终值的问题。
简单来说，提案者发出提案后，收到一些反馈，有两种结果，一种结果是自己的提案被大多数节点接受了，另外一种是没被接受，没被接受就过会再试试。
提案者收到来自大多数的接受反馈，也不能认为这就是最终确认。因为这些接收者并不知道自己刚反馈的提案就是全局的绝对大多数。
所以，引入新的一轮再确认阶段是必须的，提案者在判断这个提案可能被大多数接受的情况下，发起一轮新的确认提案。这就进入了提交阶段。
提交阶段的提案发送出去，其他阶段进行提案值比较，返回最大的，所以提案者收到返回消息不带新的提案，说明锁定成功，如果有新的提案内容，进行提案值最大比较，然后替换更大的值。如果没有收到足够多的回复，则需要再次发出请求。
一旦多数接受了共同的提案值，则形成决议，称为最终确认的提案。
Raft算法是Paxos算法的一种简化实现。
包括三种角色：leader，candidate和follower。
其有两个基本过程：
Raft一致性算法是通过选出一个leader来简化日志副本的管理，例如，，日志项（log entry）只允许从leader流向follower。
下面是动画演示Raft，清晰理解Raft共识如何达成。
Quorum介绍（二）：Quorum共识
我们知道，公共区块链是一个开放的社区，任何人都能够成为一个节点加入网络，在网络中计算，提交交易到链上等，因此公链是没有信任基础的，所以公链的共识第一要义就是证明交易的合法性和真实性，防止恶意成员的捣乱，效率不是第一要义。
与公链的环境不同，有准入门槛的企业链或者联盟链链上的所有成员在加入时实际上是已经获得了某些认可和许可的，因此企业链/联盟链上的成员是有一定信任基础的。在企业级链上我们没有必要使用POW或者POS这种浪费算力或者低效的交易共识。
Quorum提供了多种共识供用户采用：
在讲Raft前，有必要提一下Paxos算法，Paxos算法是Leslie Lamport于1990年提出的基于消息传递的一致性算法。然而，由于算法难以理解，刚开始并没有得到很多人的重视。其后，作者在八年后，也就是1998年在ACM上正式发表，然而由于算法难以理解还是没有得到重视。而作者之后用更容易接受的方法重新发表了一篇论文《Paxos Made Simple》。
可见，Paxos算法是有多难理解，即便现在放到很多高校，依然很多学生、教授都反馈Paxos算法难以理解。同时，Paxos算法在实际应用实现的时候也是比较困难的。这也是为什么会有后来Raft算法的提出。
Raft是实现分布式共识的一种算法，主要用来管理日志复制的一致性。它和Paxos的功能是一样，但是相比于Paxos，Raft算法更容易理解、也更容易应用到实际的系统当中。而Raft算法也是联盟链采用比较多的共识算法。
Raft一共有三种角色状态：
每个节点上都有一个倒计时器 (Election Timeout)，时间随机在 150ms 到 300ms 之间。有几种情况会重设 Timeout：
在分布式系统中，“时间同步”是一个很大的难题，因为每个机器可能由于所处的地理位置、机器环境等因素会不同程度造成时钟不一致，但是为了识别“过期信息”，时间信息必不可少。
Raft算法中就采用任期（Term）的概念，将时间切分为一个个的Term（同时每个节点自身也会本地维护currentTerm），可以认为是逻辑上的时间，如下图。
每一任期的开始都是一次领导人选举，一个或多个候选人（Candidate）会尝试成为领导（Leader）。如果一个人赢得选举，就会在该任期（Term）内剩余的时间担任领导人。在某些情况下，选票可能会被评分，有可能没有选出领导人（如t3），那么，将会开始另一任期，并且立刻开始下一次选举。Raft 算法保证在给定的一个任期最少要有一个领导人。
特殊情况的处理
在以太坊中节点本身并没有角色，因此在使用Raft共识时，我们称leader节点为挖矿节点：
Raft共识机制本身保证了同一时间点最多只有一个leader，因此用在以太坊模型下也只会有一个出块者，避免了同时出块或者算力浪费的情况。
在单笔交易(transaction)层级Quorum依然沿用了Ethereum的p2p传输机制，只有在块(block)层级才会使用Raft的传输机制。
其中需要注意到一点，在以太坊中一个节点收到块以后就会立刻记账，而在Quorum模型中，一个块的记录必须遵从Raft协议，每个节点从leader处收到块以后必须报告给leader确认收到以后，再由leader通知各个节点进行数据提交（记录）
在Quorum模型中新块的信息是很有可能和已有块的header信息不符的，最容易发生这种情况的就是选举人更替(挖矿节点更替)，具体描述如下：
假设有两个节点，node1和node2，node1是现有的leader，现有链的最新区块是0xbeda，它的父区块是0xacaa
对块“Extends”或者“No-op”的标记是在更上层完成的，并不由raft本身log记录机制实现。因为在raft内部，信息并不分为有效或无效，只有在区块链层面才会有有效区块和无效区块的含义。
需要注意的是，Quorum的这种记账机制和本身Ethereum的LVC（最长链机制）是完全不一样的
Quorum的出块频率默认是50ms一个块，可以通过 --raftblocktime 参数进行设置
投机性出块并不是以太坊Raft共识严格必须的核心机制之一，但是是提高出块效率的有效方式。
一个块从产生到实际被记录账本，走完整个raft流程实际上是需要耗费一定时间的。如果我们在上一个块被计入账本之后才开始产生下一个块，那么一笔交易想要成功被记录需要耗费较多的时间。
而在投机性(speculative minting)出块中，我们允许一个新块在它的父块被记录之前就产生。依次类推，在一段时间内，实际上会产生“投机链（speculative chain）”，在祖先块没有被记录进账本之前，一个一个新块已经依据先后关系组成了一条临时链片段，等待被记录。
对于已经被记录进投机块的交易，我们会在交易池中标记为“proposed transaction”
在之前我们说过，raft机制中是存在两个挖矿节点比赛出块和记账的可能的，因此，一条 speculative chain 中间的某一个块很有可能不会被记录到账本中。在这种情况下我们也会把交易池中的交易状态修改回来。( InvalidRaftOrdering event)
目前，Quorum并没有对speculative chain的长度做限制，但在它的未来规划中有讲这一点作为一个性能优化项加入开发进程，最后能够让一个挖矿节点即使在raft共识层没有连接上，它也可以离线一直出块，产生自己的speculative chain。
一条speculative chain有以下几个部分构成：
在块传输上我们使用etcd Raft默认的http传输，当然使用Ethereum的p2p传输也是可以的，但是Quorum团队在测试阶段发现，高负载的状态下，ETH p2p的性能没有raft p2p性能好。
Quorum使用50400端口作为Raft 传输层的默认监听端口，也可以通过 --raftport 参数自行设置。
一个集群默认的最大节点个数是25，可以通过 --maxpeers N 来设置，N是你的最大节点个数。
Quorum的IBFT其实就是PBFT，只不过摩根大通把它自己实现的PBFT叫做IBFT，所以IBFT的基本原理与PBFT是一样的，所不同的是,IBFT中把出块和共识的三阶段结合在了一起。
Istanbul BFT修改自PBFT算法，包括三个阶段： PRE-PREPARE 、 PREPARE 以及 COMMIT 。在 N 个节点的网络中，这个算法可以最多容忍 F 个出错节点，其中 N=3F+1 。
Istanbul BFT算法中的区块是确定的，意味着链没有分叉并且合法的区块一定是在链中。为了防止一个恶意节点生成不同的链，在把区块插入进链 之前 ，每一个validator必须把 2F + 1 个 COMMIT 签名放进区块头的 extraData 字段。因此，区块是可以自我验证的（因为有签名）并且轻客户端也支持。
然而动态的 extraData 也会造成区块的hash计算问题。因为一个区块可以被不同的validator验证，所以会有不同的签名，所以同一个区块会有不同的hash。解决的方案是，计算区块hash的时候把 COMMIT 签名排除在外。因此我们任然可以在保证block hash一致性的同时进行共识验证。
由于Ethereum POA共识在网上已经有大量介绍，笔者这里就不多做详细介绍，只对重要特点和POA的工作流程做大致梳理和介绍
常见选主机制（zab、raft）
Zab协议有四个阶段
Leader election
Discovery (E#epoch establish)
Synchronization (5X#sync with followers)
Broadcast
比如3个节点选举leader：编号为1、2、3。1先启动，选择自己为leader，然后2启动首先也选择自己为leader，由于1,2都没过半，选择编号大的为leader，所以1、2都选择2为leader，然后3启动发现1，2已经协商好且数量过半，于是3也选择2为leader，leader选举结束。
1.定义
Raft是工程上使用较为广泛的强一致、去中心化、高可用的分布式协议。是一种共识算法。
2.选主流程
Raft算法定义了三种角色：
Leader（领导者）
Follower（追随者）
Candidate（候选者）
初始状态下集群所有节点都是Follower，每一个节点都有自己的计时器，当计时达到了超时时间（Election Timeout），该节点会转变为Candidate，成为Candidate的节点，会首先给自己投票，然后向集群中其他所有的节点发起请求，要求大家都给自己投票，其他收到投票请求且还未投票的Follower节点会向发起者投票，发起者收到反馈通知后，票数增加。
得票数超过了集群节点数量的一半，该节点晋升为Leader节点。Leader节点会立刻向其他节点发出通知，告诉大家自己是领导者。收到通知的节点全部变为Follower，并且各自的计时器清零。如果发现有节点票数相同，那么会随机休息一段时间，再次发起投票，由于时间是随机，所以避免再次票数相同的概率
选出 Leader 后，Leader 通过定期向所有 Follower 发送心跳信息维持其统治。若 Follower 一段时间未收到 Leader 的心跳则认为 Leader 可能已经挂了再次发起选主过程
3.数据同步
1.由客户端提交数据到Leader节点
2.Leader 节点接收到的数据处于未提交状态（Uncommitted）
3.由Leader节点把数据复制到集群内所有的Follower节点
4.Follower节点们接收到复制的数据，会反馈给Leader节点
5.如果Leader节点接收到超过半数的Follower反馈，表明复制成功，向 Client 确认数据已接收
6.一旦向 Client 发出数据接收 Ack 响应后，表明此时数据状态进入已提交（Committed）
7.再由Leader节点通知集群内所有的Follower节点提交数据，从而完成数据同步流程
3.1 脑裂及解决方法
1. Quorums（法定人数）， 过半机制 ：默认方式， 比如3个节点的集群，Quorums = 2, 也就是说集群可以容忍1个节点失效，这时候还能选举出1个leader，集群还可用。比如4个节点的集群，它的Quorums = 3，Quorums要超过3，相当于集群的容忍度还是1，如果2个节点失效，那么整个集群还是无效的。
2. 冗余通信：采用多种通信方式，避免因一种通信终端导致脑裂。
3.智能磁盘锁： 正在服务一方锁住共享磁盘，"裂脑"发生时，让对方完全"抢不走"共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动"解锁"，另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了"智能"锁。即正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。平时就不上锁了。
4. 设置仲裁机制： 例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下 参考IP，不通则表明断点就出在本端，不仅"心跳"、还兼对外"服务"的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。
3.2 羊群效应
宕机的那个Broker上的Partition比较多， 会造成多个Watch被触发，造成集群内大量的调整，导致大量网络阻塞
3.3 zookeeper负载过重
每个Replica都要为此在ZooKeeper上注册一个Watch，当集群规模增加到几千个Partition时 ZooKeeper负载会过重
区块链的共识机制
一、区块链共识机制的目标
区块链是什么？简单而言，区块链是一种去中心化的数据库，或可以叫作分布式账本(distributed ledger)。传统上所有的数据库都是中心化的，例如一间银行的账本就储存在银行的中心服务器里。中心化数据库的弊端是数据的安全及正确性全系于数据库运营方（即银行），因为任何能够访问中心化数据库的人（如银行职员或黑客）都可以破坏或修改其中的数据。
而区块链技术则容许数据库存放在全球成千上万的电脑上，每个人的账本通过点对点网络进行同步，网络中任何用户一旦增加一笔交易，交易信息将通过网络通知其他用户验证，记录到各自的账本中。区块链之所以得其名是因为它是由一个个包含交易信息的区块（block）从后向前有序链接起来的数据结构。
很多人对区块链的疑问是，如果每一个用户都拥有一个独立的账本，那么是否意味着可以在自己的账本上添加任意的交易信息，而成千上万个账本又如何保证记账的一致性？ 解决记账一致性问题正是区块链共识机制的目标 。区块链共识机制旨在保证分布式系统里所有节点中的数据完全相同并且能够对某个提案（proposal）（例如是一项交易纪录）达成一致。然而分布式系统由于引入了多个节点，所以系统中会出现各种非常复杂的情况；随着节点数量的增加，节点失效或故障、节点之间的网络通信受到干扰甚至阻断等就变成了常见的问题，解决分布式系统中的各种边界条件和意外情况也增加了解决分布式一致性问题的难度。
区块链又可分为三种：
公有链：全世界任何人都可以随时进入系统中读取数据、发送可确认交易、竞争记账的区块链。公有链通常被认为是“完全去中心化“的，因为没有任何人或机构可以控制或篡改其中数据的读写。公有链一般会通过代币机制鼓励参与者竞争记账，来确保数据的安全性。
联盟链：联盟链是指有若干个机构共同参与管理的区块链。每个机构都运行着一个或多个节点，其中的数据只允许系统内不同的机构进行读写和发送交易，并且共同来记录交易数据。这类区块链被认为是“部分去中心化”。
私有链：指其写入权限是由某个组织和机构控制的区块链。参与节点的资格会被严格的限制，由于参与的节点是有限和可控的，因此私有链往往可以有极快的交易速度、更好的隐私保护、更低的交易成本、不容易被恶意攻击、并且能够做到身份认证等金融行业必须的要求。相比中心化数据库，私有链能够防止机构内单节点故意隐瞒或篡改数据。即使发生错误，也能够迅速发现来源，因此许多大型金融机构在目前更加倾向于使用私有链技术。
二、区块链共识机制的分类
解决分布式一致性问题的难度催生了数种共识机制，它们各有其优缺点，亦适用于不同的环境及问题。被众人常识的共识机制有：
l PoW（Proof of Work）工作量证明机制
l PoS（Proof of Stake）股权/权益证明机制
l DPoS（Delegated Proof of Stake）股份授权证明机制
l PBFT（Practical Byzantine Fault Tolerance）实用拜占庭容错算法
l DBFT（Delegated Byzantine Fault Tolerance）授权拜占庭容错算法
l SCP (Stellar Consensus Protocol ) 恒星共识协议
l RPCA（Ripple Protocol Consensus Algorithm）Ripple共识算法
l Pool验证池共识机制
（一）PoW（Proof of Work）工作量证明机制
1. 基本介绍
在该机制中，网络上的每一个节点都在使用SHA256哈希函数(hash function) 运算一个不断变化的区块头的哈希值 (hash sum)。 共识要求算出的值必须等于或小于某个给定的值。 在分布式网络中，所有的参与者都需要使用不同的随机数来持续计算该哈希值，直至达到目标为止。当一个节点的算出确切的值，其他所有的节点必须相互确认该值的正确性。之后新区块中的交易将被验证以防欺诈。
在比特币中，以上运算哈希值的节点被称作“矿工”，而PoW的过程被称为“挖矿”。挖矿是一个耗时的过程，所以也提出了相应的激励机制（例如向矿工授予一小部分比特币）。PoW的优点是完全的去中心化，其缺点是消耗大量算力造成了的资源浪费，达成共识的周期也比较长，共识效率低下，因此其不是很适合商业使用。
2. 加密货币的应用实例
比特币(Bitcoin) 及莱特币(Litecoin)。以太坊(Ethereum) 的前三个阶段（Frontier前沿、Homestead家园、Metropolis大都会）皆采用PoW机制，其第四个阶段 (Serenity宁静) 将采用权益证明机制。PoW适用于公有链。
PoW机制虽然已经成功证明了其长期稳定和相对公平，但在现有框架下，采用PoW的“挖矿”形式，将消耗大量的能源。其消耗的能源只是不停的去做SHA256的运算来保证工作量公平，并没有其他的存在意义。而目前BTC所能达到的交易效率为约5TPS（5笔/秒），以太坊目前受到单区块GAS总额的上限，所能达到的交易频率大约是25TPS，与平均千次每秒、峰值能达到万次每秒处理效率的VISA和MASTERCARD相差甚远。
3. 简图理解模式
（ps：其中A、B、C、D计算哈希值的过程即为“挖矿”，为了犒劳时间成本的付出，机制会以一定数量的比特币作为激励。）
（Ps：PoS模式下，你的“挖矿”收益正比于你的币龄(币的数量*天数)，而与电脑的计算性能无关。我们可以认为任何具有概率性事件的累计都是工作量证明，如淘金。假设矿石含金量为p% 质量, 当你得到一定量黄金时，我们可以认为你一定挖掘了1/p 质量的矿石。而且得到的黄金数量越多，这个证明越可靠。）
（二）PoS（Proof of Stake）股权/权益证明机制
1.基本介绍
PoS要求人们证明货币数量的所有权，其相信拥有货币数量多的人攻击网络的可能性低。基于账户余额的选择是非常不公平的，因为单一最富有的人势必在网络中占主导地位，所以提出了许多解决方案。
在股权证明机制中，每当创建一个区块时，矿工需要创建一个称为“币权”的交易，这个交易会按照一定比例预先将一些币发给矿工。然后股权证明机制根据每个节点持有代币的比例和时间（币龄）， 依据算法等比例地降低节点的挖矿难度，以加快节点寻找随机数的速度，缩短达成共识所需的时间。
与PoW相比，PoS可以节省更多的能源，更有效率。但是由于挖矿成本接近于0，因此可能会遭受攻击。且PoS在本质上仍然需要网络中的节点进行挖矿运算，所以它同样难以应用于商业领域。
2.数字货币的应用实例
PoS机制下较为成熟的数字货币是点点币（Peercoin）和未来币（NXT），相比于PoW，PoS机制节省了能源，引入了" 币天 "这个概念来参与随机运算。PoS机制能够让更多的持币人参与到记账这个工作中去，而不需要额外购买设备（矿机、显卡等）。每个单位代币的运算能力与其持有的时间长成正相关，即持有人持有的代币数量越多、时间越长，其所能签署、生产下一个区块的概率越大。一旦其签署了下一个区块，持币人持有的币天即清零，重新进入新的循环。
PoS适用于公有链。
3.区块签署人的产生方式
在PoS机制下，因为区块的签署人由随机产生，则一些持币人会长期、大额持有代币以获得更大概率地产生区块，尽可能多的去清零他的"币天"。因此整个网络中的流通代币会减少，从而不利于代币在链上的流通，价格也更容易受到波动。由于可能会存在少量大户持有整个网络中大多数代币的情况，整个网络有可能会随着运行时间的增长而越来越趋向于中心化。相对于PoW而言，PoS机制下作恶的成本很低，因此对于分叉或是双重支付的攻击，需要更多的机制来保证共识。稳定情况下，每秒大约能产生12笔交易，但因为网络延迟及共识问题，需要约60秒才能完整广播共识区块。长期来看，生成区块（即清零"币天"）的速度远低于网络传播和广播的速度，因此在PoS机制下需要对生成区块进行"限速"，来保证主网的稳定运行。
4.简图理解模式
（PS：拥有越多“股份”权益的人越容易获取账权。是指获得多少货币，取决于你挖矿贡献的工作量，电脑性能越好，分给你的矿就会越多。）
（在纯POS体系中，如NXT，没有挖矿过程，初始的股权分配已经固定，之后只是股权在交易者之中流转，非常类似于现实世界的股票。）
（三）DPoS（Delegated Proof of Stake）股份授权证明机制
1.基本介绍
由于PoS的种种弊端，由此比特股首创的权益代表证明机制 DPoS（Delegated Proof of Stake）应运而生。DPoS 机制中的核心的要素是选举，每个系统原生代币的持有者在区块链里面都可以参与选举，所持有的代币余额即为投票权重。通过投票，股东可以选举出理事会成员，也可以就关系平台发展方向的议题表明态度，这一切构成了社区自治的基础。股东除了自己投票参与选举外，还可以通过将自己的选举票数授权给自己信任的其它账户来代表自己投票。
具体来说， DPoS由比特股（Bitshares）项目组发明。股权拥有着选举他们的代表来进行区块的生成和验证。DPoS类似于现代企业董事会制度，比特股系统将代币持有者称为股东，由股东投票选出101名代表， 然后由这些代表负责生成和验证区块。 持币者若想称为一名代表，需先用自己的公钥去区块链注册，获得一个长度为32位的特有身份标识符，股东可以对这个标识符以交易的形式进行投票，得票数前101位被选为代表。
代表们轮流产生区块，收益（交易手续费）平分。DPoS的优点在于大幅减少了参与区块验证和记账的节点数量，从而缩短了共识验证所需要的时间，大幅提高了交易效率。从某种角度来说，DPoS可以理解为多中心系统，兼具去中心化和中心化优势。优点：大幅缩小参与验证和记账节点的数量，可以达到秒级的共识验证。缺点：投票积极性不高，绝大部分代币持有者未参与投票；另整个共识机制还是依赖于代币，很多商业应用是不需要代币存在的。
DPoS机制要求在产生下一个区块之前，必须验证上一个区块已经被受信任节点所签署。相比于PoS的" 全民挖矿 "，DPoS则是利用类似" 代表大会 "的制度来直接选取可信任节点，由这些可信任节点（即见证人）来代替其他持币人行使权力，见证人节点要求长期在线，从而解决了因为PoS签署区块人不是经常在线而可能导致的产块延误等一系列问题。 DPoS机制通常能达到万次每秒的交易速度，在网络延迟低的情况下可以达到十万秒级别，非常适合企业级的应用。 因为公信宝数据交易所对于数据交易频率要求高，更要求长期稳定性，因此DPoS是非常不错的选择。
2. 股份授权证明机制下的机构与系统
理事会是区块链网络的权力机构，理事会的人选由系统股东（即持币人）选举产生，理事会成员有权发起议案和对议案进行投票表决。
理事会的重要职责之一是根据需要调整系统的可变参数，这些参数包括：
l 费用相关：各种交易类型的费率。
l 授权相关：对接入网络的第三方平台收费及补贴相关参数。
l 区块生产相关：区块生产间隔时间，区块奖励。
l 身份审核相关：审核验证异常机构账户的信息情况。
l 同时，关系到理事会利益的事项将不通过理事会设定。
在Finchain系统中，见证人负责收集网络运行时广播出来的各种交易并打包到区块中，其工作类似于比特币网络中的矿工，在采用 PoW(工作量证明)的比特币网络中，由一种获奖概率取决于哈希算力的抽彩票方式来决定哪个矿工节点产生下一个区块。而在采用 DPoS 机制的金融链网络中，通过理事会投票决定见证人的数量，由持币人投票来决定见证人人选。入选的活跃见证人按顺序打包交易并生产区块，在每一轮区块生产之后，见证人会在随机洗牌决定新的顺序后进入下一轮的区块生产。
3. DPoS的应用实例
比特股(bitshares) 采用DPoS。DPoS主要适用于联盟链。
4.简图理解模式
（四）PBFT（Practical Byzantine Fault Tolerance）实用拜占庭容错算法
1. 基本介绍
PBFT是一种基于严格数学证明的算法，需要经过三个阶段的信息交互和局部共识来达成最终的一致输出。三个阶段分别为预备 (pre-prepare)、准备 (prepare)、落实 (commit)。PBFT算法证明系统中只要有2/3比例以上的正常节点，就能保证最终一定可以输出一致的共识结果。换言之，在使用PBFT算法的系统中，至多可以容忍不超过系统全部节点数量1/3的失效节点 (包括有意误导、故意破坏系统、超时、重复发送消息、伪造签名等的节点，又称为”拜占庭”节点)。
2. PBFT的应用实例
著名联盟链Hyperledger Fabric v0.6采用的是PBFT，v1.0又推出PBFT的改进版本SBFT。PBFT主要适用于私有链和联盟链。
3. 简图理解模式
上图显示了一个简化的PBFT的协议通信模式，其中C为客户端，0 – 3表示服务节点，其中0为主节点，3为故障节点。整个协议的基本过程如下：
(1) 客户端发送请求，激活主节点的服务操作；
(2) 当主节点接收请求后，启动三阶段的协议以向各从节点广播请求；
(a) 序号分配阶段，主节点给请求赋值一个序号n，广播序号分配消息和客户端的请求消息m，并将构造pre-prepare消息给各从节点；
(b) 交互阶段，从节点接收pre-prepare消息，向其他服务节点广播prepare消息；
(c) 序号确认阶段，各节点对视图内的请求和次序进行验证后，广播commit消息，执行收到的客户端的请求并给客户端响应。
(3) 客户端等待来自不同节点的响应，若有m+1个响应相同，则该响应即为运算的结果；
（五）DBFT（Delegated Byzantine Fault Tolerance）授权拜占庭容错算法
1. 基本介绍
DBFT建基于PBFT的基础上，在这个机制当中，存在两种参与者，一种是专业记账的“超级节点”，一种是系统当中不参与记账的普通用户。普通用户基于持有权益的比例来投票选出超级节点，当需要通过一项共识（记账）时，在这些超级节点中随机推选出一名发言人拟定方案，然后由其他超级节点根据拜占庭容错算法（见上文），即少数服从多数的原则进行表态。如果超过2/3的超级节点表示同意发言人方案，则共识达成。这个提案就成为最终发布的区块，并且该区块是不可逆的，所有里面的交易都是百分之百确认的。如果在一定时间内还未达成一致的提案，或者发现有非法交易的话，可以由其他超级节点重新发起提案，重复投票过程，直至达成共识。
2. DBFT的应用实例
国内加密货币及区块链平台NEO是 DBFT算法的研发者及采用者。
3. 简图理解模式
假设系统中只有四个由普通用户投票选出的超级节点，当需要通过一项共识时，系统就会从代表中随机选出一名发言人拟定方案。发言人会将拟好的方案交给每位代表，每位代表先判断发言人的计算结果与它们自身纪录的是否一致，再与其它代表商讨验证计算结果是否正确。如果2/3的代表一致表示发言人方案的计算结果是正确的，那么方案就此通过。
如果只有不到2/3的代表达成共识，将随机选出一名新的发言人，再重复上述流程。这个体系旨在保护系统不受无法行使职能的领袖影响。
上图假设全体节点都是诚实的，达成100%共识，将对方案A（区块）进行验证。
鉴于发言人是随机选出的一名代表，因此他可能会不诚实或出现故障。上图假设发言人给3名代表中的2名发送了恶意信息（方案B），同时给1名代表发送了正确信息（方案A）。
在这种情况下该恶意信息（方案B）无法通过。中间与右边的代表自身的计算结果与发言人发送的不一致，因此就不能验证发言人拟定的方案，导致2人拒绝通过方案。左边的代表因接收了正确信息，与自身的计算结果相符，因此能确认方案，继而成功完成1次验证。但本方案仍无法通过，因为不足2/3的代表达成共识。接着将随机选出一名新发言人，重新开始共识流程。
上图假设发言人是诚实的，但其中1名代表出现了异常；右边的代表向其他代表发送了不正确的信息（B）。
在这种情况下发言人拟定的正确信息（A）依然可以获得验证，因为左边与中间诚实的代表都可以验证由诚实的发言人拟定的方案，达成2/3的共识。代表也可以判断到底是发言人向右边的节点说谎还是右边的节点不诚实。
（六）SCP (Stellar Consensus Protocol ) 恒星共识协议
1. 基本介绍
SCP 是 Stellar (一种基于互联网的去中心化全球支付协议) 研发及使用的共识算法，其建基于联邦拜占庭协议 (Federated Byzantine Agreement) 。传统的非联邦拜占庭协议（如上文的PBFT和DBFT）虽然确保可以通过分布式的方法达成共识，并达到拜占庭容错 (至多可以容忍不超过系统全部节点数量1/3的失效节点)，它是一个中心化的系统 — 网络中节点的数量和身份必须提前知晓且验证过。而联邦拜占庭协议的不同之处在于它能够去中心化的同时，又可以做到拜占庭容错。
[…]
（七）RPCA（Ripple Protocol Consensus Algorithm）Ripple共识算法
1. 基本介绍
RPCA是Ripple（一种基于互联网的开源支付协议，可以实现去中心化的货币兑换、支付与清算功能）研发及使用的共识算法。在 Ripple 的网络中，交易由客户端（应用）发起，经过追踪节点（tracking node）或验证节点（validating node）把交易广播到整个网络中。追踪节点的主要功能是分发交易信息以及响应客户端的账本请求。验证节点除包含追踪节点的所有功能外，还能够通过共识协议，在账本中增加新的账本实例数据。
Ripple 的共识达成发生在验证节点之间，每个验证节点都预先配置了一份可信任节点名单，称为 UNL（Unique Node List）。在名单上的节点可对交易达成进行投票。共识过程如下：
(1) 每个验证节点会不断收到从网络发送过来的交易，通过与本地账本数据验证后，不合法的交易直接丢弃，合法的交易将汇总成交易候选集（candidate set）。交易候选集里面还包括之前共识过程无法确认而遗留下来的交易。
(2) 每个验证节点把自己的交易候选集作为提案发送给其他验证节点。
(3) 验证节点在收到其他节点发来的提案后，如果不是来自UNL上的节点，则忽略该提案；如果是来自UNL上的节点，就会对比提案中的交易和本地的交易候选集，如果有相同的交易，该交易就获得一票。在一定时间内，当交易获得超过50%的票数时，则该交易进入下一轮。没有超过50%的交易，将留待下一次共识过程去确认。
(4) 验证节点把超过50%票数的交易作为提案发给其他节点，同时提高所需票数的阈值到60%，重复步骤(3)、步骤(4)，直到阈值达到80%。
(5) 验证节点把经过80%UNL节点确认的交易正式写入本地的账本数据中，称为最后关闭账本（last closed ledger），即账本最后（最新）的状态。
在Ripple的共识算法中，参与投票节点的身份是事先知道的，因此，算法的效率比PoW等匿名共识算法要高效，交易的确认时间只需几秒钟。这点也决定了该共识算法只适合于联盟链或私有链。Ripple共识算法的拜占庭容错（BFT）能力为（n-1）/5，即可以容忍整个网络中20%的节点出现拜占庭错误而不影响正确的共识。
2. 简图理解模式
共识过程节点交互示意图：
共识算法流程：
（八）POOL验证池共识机制
Pool验证池共识机制是基于传统的分布式一致性算法（Paxos和Raft）的基础上开发的机制。Paxos算法是1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。过去, Paxos一直是分布式协议的标准，但是Paxos难于理解，更难以实现。Raft则是在2013年发布的一个比Paxos简单又能实现Paxos所解决问题的一致性算法。Paxos和Raft达成共识的过程皆如同选举一样，参选者需要说服大多数选民(服务器)投票给他，一旦选定后就跟随其操作。Paxos和Raft的区别在于选举的具体过程不同。而Pool验证池共识机制即是在这两种成熟的分布式一致性算法的基础上，辅之以数据验证的机制。
详解分布式共识（一致性）算法Raft
所谓分布式共识（consensus）区块链raft算法，与 CAP理论 中的一致性（consistency）其实是异曲同工区块链raft算法，就是在分布式系统中，所有节点对同一份数据的认知能够达成一致。保证集群共识的算法就叫共识算法，它与一致性协议这个词也经常互相通用。
当今最著名的共识算法就是Paxos算法。它由Leslie Lamport在1990年提出，很长时间以来都是一致性的事实标准。但是它有两个不小的缺点：难以理解和证明，难以在实际工程中实现。Google Chubby的工程师就曾有以下的评论：
于是2014年，来自斯坦福的两位大佬Diego Ongaro与John Ousterhout通过论文 《In Search of an Understandable Consensus Algorithm》 提出了一个新的共识算法Raft。从题目就可以看出，Raft的特点就是容易理解，在此基础上也容易实现，因此在real world中，它的应用也比Paxos要广泛，比较有名的如etcd、Kudu等。
Raft为了达到易懂易用的目标，主要做了两件事：一是分解问题（decomposition），即将复杂的分布式共识问题拆分为 领导选举 （leader election）、 日志复制 （log replication）和 安全性 （safety）三个子问题，并分别解决；二是压缩状态空间（state space reduction），相对于Paxos算法而言施加了更合理的限制，减少因为系统状态过多而产生的不确定性。
下面先简要介绍共识算法的基础——复制状态机，然后就来按顺序研究Raft是如何解决三个子问题的。
在共识算法中，所有服务器节点都会包含一个有限状态自动机，名为复制状态机（replicated state machine）。每个节点都维护着一个复制日志（replicated logs）的队列，复制状态机会按序输入并执行该队列中的请求，执行状态转换并输出结果。可见，如果能保证各个节点中日志的一致性，那么所有节点状态机的状态转换和输出也就都一致。共识算法就是为了保障这种一致性的，下图示出简单的复制状态机及其相关架构。
根据分布式系统的 Quorum机制 与NRW算法，集群中半数以上节点可用时，就能正确处理分布式事务，因此Raft集群几乎都使用奇数节点，可以防止脑裂并避免浪费资源。采用ZAB协议的ZooKeeper集群也是如此。
在Raft集群中，任意节点同一时刻只能处于领导者（leader）、跟随者（follower）、候选者（candidate）三种状态之一。下图示出节点状态的转移规则。
可见，集群建立时所有节点都是跟随节点。如果在一定时间过后发现没有领导节点，就会切换到候选状态，发起选举。得到多数票的候选者就会成为领导节点。如果候选节点或当前领导节点发现了更新的领导者，就会主动退回跟随状态。
领导节点全权负责管理复制日志，也就是从客户端接收请求，复制到跟随节点，并告诉跟随节点何时可以处理这些请求。如果领导节点故障或断开连接，就会重新进行选举。可见，领导节点的存在大大简化了共识算法的设计。
在上面的图中出现了任期（term）这个词。领导者并不是一直“在位”的，工作一段时间之后，就会选举出新的领导者来接替它。
由上图可见，蓝色表示选举时间段，绿色表示选举出的领导者在位的时间段，这两者合起来即称作一个任期，其计数值是自增的。任期的值就可以在逻辑上充当时间戳，每个节点都会保存一份自己所见的最新任期值，称为currentTerm。另外，如果因为票数相同，没能选出领导，就会立即再发起新的选举。
如果一个或多个跟随节点在选举超时（election timeout）内没有收到领导节点的心跳（一个名为AppendEntries的RPC消息，本意是做日志复制用途，但此时不携带日志数据），就会发起选举流程：
根据其区块链raft算法他节点回复的消息，会出现如下三种结果：
获得多数票的节点只要当选，就会立即给其他所有节点发送AppendEntries，避免再次选举。另外，在同一任期内，每个节点只能投一票，并且先到先得（first-come-first-served），也就是会把票投给RequestVote消息第一个到达的那个节点。
至于上面的第三种情况，也就是所谓“split vote”现象，容易在很多跟随者变成候选者时出现，因为没有节点能得到多数票，选举有可能无限继续下去。所以，Raft设置的选举超时并不是完全一样的，而是有些许随机性，来尽量使得投票能够集中到那些较“快”的节点上。
领导节点选举出来后，集群就可以开始处理客户端请求了。前面已经说过，每个节点都维护着一个复制日志的队列，它们的格式如下图所示。
可见，日志由一个个按序排列的entry组成。每个entry内包含有请求的数据，还有该entry产生时的领导任期值。在论文中，每个节点上的日志队列用一个数组log[]表示。
当客户端发来请求时，领导节点首先将其加入自己的日志队列，再并行地发送AppendEntries RPC消息给所有跟随节点。领导节点收到来自多数跟随者的回复之后，就认为该请求可以提交了（见图中的commited entries）。然后，领导节点将请求应用（apply）到复制状态机，并通知跟随节点也这样做。这两步做完后，就不会再回滚。
这种从提交到应用的方式与最基础的一致性协议——两阶段提交（2PC）有些相似，但Raft只需要多数节点的确认，并不需要全部节点都可用。
注意在上图中，领导节点和4个跟随节点的日志并不完全相同，这可能是由于跟随节点反应慢、网络状况差等原因。领导节点会不断地重试发送AppendEntries，直到所有节点上的日志达到最终一致，而不实现强一致性。这就是CAP理论中在保证P的情况下，C与A无法兼得的体现。
日志复制的过程仍然遗留了一个问题：如果领导或者跟随节点发生异常情况而崩溃，如何保证日志的最终一致性？它属于下面的安全性问题中的一部分，稍后会解答它。
安全性是施加在领导选举、日志复制两个解决方案上的约束，用于保证在异常情况下Raft算法仍然有效，不能破坏一致性，也不能返回错误的结果。所有分布式算法都应保障安全性，在其基础上再保证活性（liveness）。
Raft协议的安全性保障有5种，分别是：选举安全性（election safety）、领导者只追加（leader append-only）、日志匹配（log matching）、领导者完全性（leader completeness）、状态机安全性（state machine safety） 。下面分别来看。
选举安全性是指每个任期内只允许选出最多一个领导。如果集群中有多于一个领导，就发生了脑裂（split brain）。根据“领导选举”一节中的描述，Raft能够保证选举安全，因为：
在讲解日志复制时，我们可以明显地看出，客户端发出的请求都是插入领导者日志队列的尾部，没有修改或删除的操作。这样可以使领导者的行为尽量简单化，使之没有任何不确定的行为，同时也作为下一节要说的日志匹配的基础。
日志匹配的具体描述如下。
如果两个节点的日志队列中，两个entry具有相同的下标和任期值，那么：
第一点自然由上一节的“领导者只追加”特性来保证，而第二点则由AppendEntries RPC消息的一个简单机制来保证：每条AppendEntries都会包含最新entry之前那个entry的下标与任期值，如果跟随节点在对应下标找不到对应任期的日志，就会拒绝接受并告知领导节点。
有了日志匹配特性，就可以解决日志复制中那个遗留问题了。假设由于节点崩溃，跟随节点的日志出现了多种异常情况，如下图。
注意图中不是6个跟随节点，而是6种可能的情况。比如a和b是丢失了entry，c和d是有多余的未提交entry，e和f则是既有丢失又有冗余。这时领导节点就会找到两个日志队列中最近一条匹配的日志点，将该点之后跟随节点的所有日志都删除，然后将自己的这部分日志复制给它。例如对于上图中的情况e来说，最近一条匹配的日志下标为5，那么5之后的所有entry都会被删除，被替换成领导者的日志。
领导者完全性是指，如果有一条日志在某个任期被提交了，那么它一定会出现在所有任期更大的领导者日志里。这也是由两点来决定的：
根据这两个描述，每次选举出的领导节点一定包含有最新的日志，因此只存在跟随节点从领导节点更新日志的情况，而不会反过来，这也使得一致性逻辑更加简化，并且为下面的状态机安全性提供保证。
状态机安全性是说，如果一个节点已经向其复制状态机应用了一条日志中的请求，那么对于其他节点的同一下标的日志，不能应用不同的请求。这句话就很拗口了，因此我们来看一种意外的情况。
这里就有问题了，在时刻c的日志与新领导者的日志发生了冲突，此时状态机是不安全的。
为了解决该问题，Raft不允许领导者在当选后提交“前任”的日志，而是通过日志匹配原则，在处理“现任”日志时将之前的日志一同提交。具体方法是：在领导者任期开始时，立刻提交一条空的日志，所以上图中时刻c的情况不会发生，而是像时刻e一样先提交任期4的日志，连带提交任期2的日志。就算此时S1再崩溃，S5也不会重新被选举了。
如果想要更直观地理解Raft，建议参考 这里 ，是一个用动画来描述该算法的网页，形象生动。
写到这里，本文关于区块链raft算法和raft算法详解的介绍到此为止了，如果能碰巧解决你现在面临的问题，如果你还想更加了解这方面的信息，记得收藏关注本站。
标签： #区块链raft算法
评论列表