作为虚拟币行业人士而言，我们经常都会说到拜占庭将军问题是什么时有很多细节是需要注意的。你知道拜占庭将军共识？今天就让小编跟你们说说吧！

拜占庭问题

拜占庭帝国即中世纪的土耳其，拥有巨大的财富，周围10个邻邦垂诞已久，但拜占庭高墙耸立，固若金汤，没有一个单独的邻邦能够成功入侵。任何单个邻邦入侵的都会失败，同时也有可能自身被其他9个邻邦入侵。拜占庭帝国防御能力如此之强，至少要有十个邻邦中的一半以上同时进攻，才有可能攻破。

然而，如果其中的一个或者几个邻邦本身答应好一起进攻，但实际过程出现背叛，那么入侵者可能都会被歼灭。

于是每一方都小心行事，不敢轻易相信邻国。这就是拜占庭将军问题。

在拜占庭问题中，最重要的point就是： 所有将军如何达成一致攻打拜占庭的共识 ，这当中，可能出现的情况举例如下：

用一个模型解释一下：

假设只有3个人，A、B、C，三人中如果其中一个是叛徒。当A发出进攻命令时，B如果是叛徒，他可能告诉C，他收到的是“撤退”的命令。这时C收到一个“进攻”，一个“撤退“，于是C被信息迷惑，而无所适从。

如果A是叛徒。他告诉B“进攻”，告诉C“撤退”。当C告诉B，他收到“撤退”命令时，B由于收到了司令“进攻”的命令，而无法与C保持一致。

正由于上述原因，在只有三个角色的系统中，只要有一个是叛徒，即叛徒数等于1/3，拜占庭问题便不可解。

可以看得出， 只要叛徒的数量大于或等于1/3，拜占庭问题不可解

从技术上理解， 拜占庭将军问题是分布式系统容错性问题 。加密货币建立在P2P网络之上，是典型的分布式系统，类比一下， 将军就是P2P网络中的节点，信使就是节点之间的通信，进攻还是撤退的决定就是需要达成的共识 。 如果某台独立的节点计算机拓机、掉线或攻击网络搞破坏，整个系统就要停止运行，那这样的系统将非常脆弱，所以容许部分节点出错或搞破坏而不影响整个系统运行是必要的 ， 这就需要算法理论上的支撑，保证分布式系统在一定量的错误节点存在的情况下，仍然保持一致性和可用性 。

而且，拜占庭将军与两军问题不同，前者假定信差没有问题，只是将军出现了叛变等问题；后者研究信差的通信问题。

终极解决方案到了——

如果 10个将军中的几个同时发起消息，势必会造成系统的混乱，造成各说各的攻击时间方案，行动难以一致 。

谁都可以发起进攻的信息，但由谁来发出呢？中本聪巧妙地在个系统加入了 发送信息的成本 ，即：

它加入的 成本就是”工作量“ —— 节点必须完成一个计算工作才能向各城邦传播消息 ，当然，谁第一个完成工作，谁才能传播消息。（这也是 工作量证明机制的意义：以检验结果的方式证明你过去所做过了多少工作 ）

这种加密技术——非对称加密，完全可以解决古代难以解决的签名问题：

中本聪在设计比特币时，它采用了一种工作量证明机制叫哈希现金，在一个交易块这要找到一个随机数，计算机只能用穷举法来找到这个随机数，可以说，能不能找到全靠运气，所以对于各个节点来说，这个世界上，只有随机才是真正的公平，实现随机的最好办法是使用数学，所有的将军在寻找共识的过程，借助了大家都认可的数学逻辑。

当然了， 凭什么要义务进行计算工作，那么肯定要有一个激励机制 ：比特币的奖励机制是每打包一个块，目前是奖励25个比特币，而拜占庭将军问题的奖励机制可以是瓜分拜占庭获得的利益。

在这个分布式网络里：

每个将军都有一份实时与其他将军同步的消息账本 。

账本里有每个将军的签名都是可以验证身份的。 如果有哪些消息不一致，可以知道消息不一致的是哪些将军 。

尽管有消息不一致的，只要超过半数同意进攻，少数服从多数，共识达成（只要大多数是好人，那么就可以实现共识）。

区块链上的共识机制主要解决 由谁来构造区块 ，以及 如何维护区块链统一 的问题。

拜占庭容错问题需要解决的也同样是 谁来发起信息 ，如何 实现信息的统一同步 的问题。

注：区块链学习新人，若有不正确的地方，望指出

如何理解拜占庭将军问题

拜占庭将军问题（Byzantine failures）又称两军问题，是由莱斯利·兰伯特提出的点对点通信中的基本问题。含义是在存在消息丢失的不可靠信道上试图通过消息传递的方式达到一致性是不可能的。因此对一致性的研究一般假设信道是可靠的，或不存在本问题。

共识算法：Raft

上篇讲到了「拜占庭将军问题」：多个拜占庭将军要如何在可能有叛徒、信使可能被策反或者暗杀的情况下达成是否要进攻的一致性决定？还不了解的先看看上一篇 《拜占庭将军问题》 。这篇主要是介绍简化版拜占庭将军问题的解决方案：Raft 共识算法。

所以将拜占庭将军问题根据常见的工作上的问题进行简化： 假设将军中没有叛军，信使的信息可靠但有可能被暗杀的情况下，将军们如何达成一致性决定？

对于这个简化后的问题，有许多解决方案，第一个被证明的共识算法是 Paxos，由拜占庭将军问题的作者 Leslie Lamport 在1990年提出，最初以论文难懂而出名，后来这哥们在2001重新发了一篇简单版的论文 Paxos Made Simple ，然而还是挺难懂的。

因为 Paxos 难懂，难实现，所以斯坦福大学的教授在2014年发表了新的分布式协议 Raft。与 Paxos 相比，Raft 有着基本相同运行效率，但是更容易理解，也更容易被用在系统开发上。

我们还是用拜占庭将军的例子来帮助理解 Raft。

Raft 的解决方案大概可以理解成 先在所有将军中选出一个大将军，所有的决定由大将军来做。 选举环节 ：比如说现在一共有3个将军 A, B, C，每个将军都有一个 随机时间 的倒计时器，倒计时一结束，这个将军就会把自己当成大将军候选人，然后派信使去问其他几个将军，能不能选我为总将军？假设现在将军A倒计时结束了，他派信使传递选举投票的信息给将军B和C，如果将军B和C还没把自己当成候选人（倒计时还没有结束），并且没有把选举票投给其他，他们把票投给将军A，信使在回到将军A时，将军A知道自己收到了足够的票数，成为了大将军。在这之后，是否要进攻就由大将军决定，然后派信使去通知另外两个将军，如果在一段时间后还没有收到回复（可能信使被暗杀），那就再重派一个信使，直到收到回复。

故事先讲到这里，希望不做技术方面的朋友可以大概能理解 Raft 的原理，下面从比较技术的角度讲讲 Raft 的原理。

从拜占庭将军的故事映射到分布式系统上，每个将军相当于一个分布式网络节点，每个节点有 三种状态：Follower，Candidate，Leader ，状态之间是互相转换的，可以参考下图，具体的后面说。

每个节点上都有一个倒计时器 (Election Timeout)，时间随机在 150ms 到 300ms 之间。有几种情况会重设 Timeout：

在 Raft 运行过程中，最主要进行两个活动：

假设现在有如图5个节点，5个节点一开始的状态都是 Follower。

在一个节点倒计时结束 (Timeout) 后，这个节点的状态变成 Candidate 开始选举，它给其他几个节点发送选举请求 (RequestVote)

其他四个节点都返回成功，这个节点的状态由 Candidate 变成了 Leader，并在每个一小段时间后，就给所有的 Follower 发送一个 Heartbeat 以保持所有节点的状态，Follower 收到 Leader 的 Heartbeat 后重设 Timeout。

这是最简单的选主情况， 只要有超过一半的节点投支持票了，Candidate 才会被选举为 Leader ，5个节点的情况下，3个节点 (包括 Candidate 本身) 投了支持就行。

一开始已经有一个 Leader，所有节点正常运行。

Leader 出故障挂掉了，其他四个 Follower 将进行重新选主。

4个节点的选主过程和5个节点的类似，在选出一个新的 Leader 后，原来的 Leader 恢复了又重新加入了，这个时候怎么处理？在 Raft 里，第几轮选举是有记录的，重新加入的 Leader 是第一轮选举 (Term 1) 选出来的，而现在的 Leader 则是 Term 2，所有原来的 Leader 会自觉降级为 Follower

假设一开始有4个节点，都还是 Follower。

有两个 Follower 同时 Timeout，都变成了 Candidate 开始选举，分别给一个 Follower 发送了投票请求。

两个 Follower 分别返回了ok，这时两个 Candidate 都只有2票，要3票才能被选成 Leader。

两个 Candidate 会分别给另外一个还没有给自己投票的 Follower 发送投票请求。

但是因为 Follower 在这一轮选举中，都已经投完票了，所以都拒绝了他们的请求。所以在 Term 2 没有 Leader 被选出来。

这时，两个节点的状态是 Candidate，两个是 Follower，但是他们的倒计时器仍然在运行，最先 Timeout 的那个节点会进行发起新一轮 Term 3 的投票。

两个 Follower 在 Term 3 还没投过票，所以返回 OK，这时 Candidate 一共有三票，被选为了 Leader。

如果 Leader Heartbeat 的时间晚于另外一个 Candidate timeout 的时间，另外一个 Candidate 仍然会发送选举请求。

两个 Follower 已经投完票了，拒绝了这个 Candidate 的投票请求。

Leader 进行 Heartbeat， Candidate 收到后状态自动转为 Follower，完成选主。

以上是 Raft 最重要活动之一选主的介绍，以及在不同情况下如何进行选主。

总结：

1.每个节点一直有一个timeout，timeout结束就开始选自己为主节点；

2.主节点会轮询从节点，从节点更新timeout；

3.选举等级机制；

Raft 在实际应用场景中的一致性更多的是体现在不同节点之间的数据一致性，客户端发送请求到任何一个节点都能收到一致的返回，当一个节点出故障后，其他节点仍然能以已有的数据正常进行。在选主之后的复制日志就是为了达到这个目的。

一开始，Leader 和 两个 Follower 都没有任何数据。

客户端发送请求给 Leader，储存数据 “sally”，Leader 先将数据写在本地日志，这时候数据还是 Uncommitted (还没最终确认，红色表示)

Leader 给两个 Follower 发送 AppendEntries 请求，数据在 Follower 上没有冲突，则将数据暂时写在本地日志，Follower 的数据也还是 Uncommitted。

Follower 将数据写到本地后，返回 OK。Leader 收到后成功返回， 只要收到的成功的返回数量超过半数 (包含Leader) ，Leader 将数据 “sally” 的状态改成 Committed。( 这个时候 Leader 就可以返回给客户端了)

Leader 再次给 Follower 发送 AppendEntries 请求，收到请求后，Follower 将本地日志里 Uncommitted 数据改成 Committed。这样就完成了一整个复制日志的过程，三个节点的数据是一致的，

在 Network Partition 的情况下，部分节点之间没办法互相通信，Raft 也能保证在这种情况下数据的一致性。

一开始有 5 个节点处于同一网络状态下。

Network Partition 将节点分成两边，一边有两个节点，一边三个节点。

两个节点这边已经有 Leader 了，来自客户端的数据 “bob” 通过 Leader 同步到 Follower。

因为只有两个节点，少于3个节点，所以 “bob” 的状态仍是 Uncommitted。所以在这里， 服务器会返回错误给客户端

另外一个 Partition 有三个节点，进行重新选主。客户端数据 “tom” 发到新的 Leader，通过和上节网络状态下相似的过程，同步到另外两个 Follower。

因为这个 Partition 有3个节点，超过半数，所以数据 “tom” 都 Commit 了。

网络状态恢复，5个节点再次处于同一个网络状态下。但是这里出现了数据冲突 “bob" 和 “tom"

三个节点的 Leader 广播 AppendEntries

两个节点 Partition 的 Leader 自动降级为 Follower，因为这个 Partition 的数据 “bob” 没有 Commit，返回给客户端的是错误，客户端知道请求没有成功，所以 Follower 在收到 AppendEntries 请求时，可以把 “bob“ 删除，然后同步 ”tom”，通过这么一个过程，就完成了在 Network Partition 情况下的复制日志，保证了数据的一致性。

Raft 是能够实现分布式系统强一致性的算法，每个系统节点有三种状态 Follower，Candidate，Leader。实现 Raft 算法两个最重要的事是：选主和复制日志

参考链接：

Raft 官网：

Raft 原理动画 (推荐看看)：

易理解的拜占庭将军问题——深入剖析

拜占庭将军问题和两军问题实质是不一样的，不能混为一谈。其中两军问题如下图所示：

两军问题描述：

和拜占庭将军问题有一定的相似性也有不同之处，所以我们必须注意的是：

两军问题的根本问题在于信道的不可靠，也就是信号做不到真正的同步，那么想要做到真正的同步唯一的办法就是量子通信——毕竟遇事不决量子搞定:

到底是一个关于一致性和正确性的算法问题。针对的是忠诚的将军，因为叛徒可以做出任何超出约定的判断。我们就是要在有叛徒的干扰下，找到一个抗干扰的算法。

类似TCP/IP的三次握手，我们也同样的是采用容错机制，通过限制一部分条件最后使得在有叛徒的情况下依然能够得到信息的真实性。

失效说明：

满足以下三个条件的方式称为口头协议：

对于正整数 和 ，当图 是 -正则的是，定义算法 OM(m, p) ：

在算法中，司令官发送一个签名的命令给他的每个副官。然后，每个副官添加他的签名到命令上，并发送给其他副官，收到命令的副官再添加他的签名发送给其他副官......

算法还假定了一个 choice 函数，作用在一个命令的集合上来获得一个单独的命令。 choice 函数需要满足：

例如， choince 函数可以是取有序集合 的中位数。

令 指由将军 签名的命令值 ， 指命令指 由将军 签名后再由将军 签名。令将军 为司令官，每个副官 维护一个命令集 ，包含他收到的被正确签名的命令值。(如果司令官是忠诚的，这个值集的元素不会超过一个)。

书面协议的结论非常令人兴奋，这不是解决了拜占庭将军问题了吗？但请注意我们在A1~A4中实际上是添加了一些条件的，这使得拜占庭将军问题在这些假设下能够解决，但是在实际状况中却会有一些问题。观察A1-A4，我们做了一些在现实中比较难以完成的假设，比如：

相信经过币圈网小编对拜占庭将军问题是什么和拜占庭将军共识的介绍，你对拜占庭将军问题是什么了解更加地透彻了，感谢你对我们地支持与关注！