Consul Consensus Protocol

Consensus Protocol（一致性协议）

Consul使用共识协议来提供一致性（由CAP定义）。共识协议基于“Raft：寻找可理解的共识算法”。有关Raft的直观解释，请参阅数据的秘密生活。

 

Raft Protocol Overview（Raft协议概述）

Raft是一种基于Paxos的共识算法。与Paxos相比，Raft被设计为具有更少的状态和更简单，更易理解的算法。

 

讨论Raft时需要了解一些关键术语：

Log -  Raft系统中的主要工作单元是日志条目。一致性问题可以分解为复制日志。日志是有序的条目序列。如果所有成员就条目及其订单达成一致，我们认为日志是一致的。

FSM  - 有限状态机。 FSM是有限状态的集合，它们之间具有转换。在应用新日志时，允许FSM在状态之间转换。应用相同的日志序列必须导致相同的状态，这意味着行为必须是确定性的。

Peer Set - 对等集是参与日志复制的所有成员的集合。出于Consul的目的，所有服务器节点都位于本地数据中心的对等集中。

Quorum - 法定人数是来自同伴集的大多数成员：对于一组大小为n，法定人数至少需要（n / 2）+1个成员。例如，如果对等集中有5个成员，我们将需要3个节点来形成仲裁。如果法定数量的节点因任何原因不可用，则群集将变为不可用，并且不能提交新日志。

Committed Entry - 条目在持续存储在法定数量的节点上时被视为已提交。一旦提交了条目，就可以应用它。

Leader - 在任何给定时间，对等集选择单个节点作为领导者。领导者负责摄取新的日志条目，复制到关注者，以及管理何时认为条目被提交。

 

Raft是一个复杂的协议，这里不再详述（对于那些需要更全面的治疗的人，本文提供了完整的规范）。但是，我们将尝试提供可用于构建心理模型的高级描述。

 

Raft节点总是处于以下三种状态之一：关注者，候选者或领导者。所有节点最初都是作为关注者开始的。在此状态下，节点可以接受来自领导者的日志条目并投票。如果在一段时间内没有收到任何条目，则节点会自我提升到候选状态。在候选状态中，节点请求来自其对等体的投票。如果候选人获得了法定人数的票数，那么它将被提升为领导者。领导者必须接受新的日志条目并复制给所有其他关注者。此外，如果陈旧读取不可接受，则还必须对领导者执行所有查询。

 

一旦集群具有领导者，它就能够接受新的日志条目。客户端可以请求领导者附加新的日志条目（从Raft的角度来看，日志条目是不透明的二进制blob）。然后，领导者将条目写入持久存储，并尝试复制到法定数量的关注者。一旦认为日志条目已提交，它就可以应用于有限状态机。有限状态机是特定于应用程序的;在Consul的案例中，我们使用MemDB来维护集群状态。 Consul的写入块直到它被提交和应用为止。当与查询的一致模式一起使用时，这实现了写后语义的读取。

 

显然，允许复制日志以无限制的方式增长是不可取的。 Raft提供了一种机制，通过该机制可以快照当前状态并压缩日志。由于FSM抽象，恢复FSM的状态必然导致与旧日志的重放相同的状态。这允许Raft在某个时间点捕获FSM状态，然后删除用于达到该状态的所有日志。这是在没有用户干预的情况下自动执行的，可以防止无限制的磁盘使用，同时还可以最大限使用MemDB的一个优点是，它允许Consul继续接受新的事务，即使在旧状态被快照时，也可以防止任何可用性问题。

 

达成一致性是容错的，直到法定人数可用。如果法定数量的节点不可用，则无法处理日志条目或关于对等成员资格的原因。例如，假设只有2个对等体：A和B.仲裁大小也是2，这意味着两个节点必须同意提交日志条目。如果A或B失败，则现在无法达到法定人数。这意味着群集无法添加或删除节点或提交任何其他日志条目。这导致不可用。此时，需要手动干预才能删除A或B，并在引导模式下重新启动剩余节点。

 

3个节点的Raft集群可以容忍单个节点故障，而5个集群可以容忍2个节点故障。建议的配置是为每个数据中心运行3或5个Consul服务器。这可以最大限度地提高可用性，而不会大大降低性能。下面的部署表总结了潜在的群集大小选项以及每个选项的容错能力。

 

在性能方面，Raft与Paxos相当。假设稳定的领导，提交日志条目需要单程往返一半的集群。因此，性能受磁盘I / O和网络延迟的约束。尽管Consul并非设计为高吞吐量写入系统，但它应该按照每秒数百到数千个事务的顺序处理，具体取决于网络和硬件配置。

 

Raft in Consul（Consul中的Raft）

只有Consul服务器节点参与Raft并且是对等集的一部分。所有客户端节点都将请求转发给服务端。这种设计的部分原因是，随着更多成员被添加到对等集中，仲裁的大小也会增加。这引入了性能问题，因为您可能正在等待数百台计算机同意一个条目而不是少数条目。

 

入门时，单个Consul服务器进入“bootstrap”模式。此模式允许它作为领导者自行选举。选举领导者后，可以以保持一致性和安全性的方式将其他服务器添加到对等集。最后，一旦添加了几个服务器，就可以禁用引导程序模式。有关详细信息，请参阅本指南。

 

由于所有服务器都作为对等集的一部分参与，因此他们都知道当前的领导者。当RPC请求到达非领导者服务器时，请求将转发给领导者。如果RPC是查询类型，意味着它是只读的，则领导者将根据FSM的当前状态生成结果。如果RPC是事务类型，意味着它修改状态，则领导者生成新的日志条目并使用Raft应用它。提交日志条目并将其应用于FSM后，事务就完成了。

 

由于Raft复制的性质，性能对网络延迟很敏感。因此，每个数据中心选择一个独立的领导者并维护一个不相交的对等集。数据由数据中心分区，因此每个领导者仅负责其数据中心中的数据。收到远程数据中心的请求后，请求将转发给正确的领导者。此设计允许更低延迟的事务和更高的可用性，而不会牺牲一致性。

 

Consistency Modes（一致性模式）

虽然对复制日志的所有写入都通过Raft进行，但读取更灵活。为了支持开发人员可能需要的各种权衡，Consul支持3种不同的读取一致性模式。

三种读取模式是：

default -  Raft利用领导租赁，提供领导者认为其角色稳定的时间窗口。但是，如果领导者与剩余的同伴分开，则可以在旧领导者持有租约时选出新的领导者。这意味着有2个领导节点。由于旧的领导者无法提交新的日志，因此不存在裂脑的风险。但是，如果旧的领导者为任何读取提供服务，则这些值可能过时。默认一致性模式仅依赖于领导者租赁，将客户端暴露给可能过时的值。我们做出这种权衡，因为读取速度快，通常强烈一致，并且只在难以触发的情况下过时。由于分区导致领导者下台，因此陈旧读取的时间窗口也是有限的。

consistent - 这种模式非常一致，没有任何警告。它要求领导者与法定人数确认它仍然是领导者。这为所有服务器节点引入了额外的往返。由于额外的往返，权衡总是一致读取但延迟增加。

stale - 此模式允许任何服务器为读取服务，无论它是否是领导者。这意味着读取可以是任意陈旧的，但通常在领导者的50毫秒内。权衡是非常快速和可扩展的读取，但具有陈旧的值。此模式允许在没有leader的情况下进行读取，这意味着无法使用的群集仍然可以响应。

有关使用这些不同模式的更多文档，请参阅HTTP API。

 

Deployment Table（部署表）

下表显示了各种群集大小的仲裁大小和容错能力。 建议的部署是3或5台服务器。 由于在故障情况下数据丢失是不可避免的，因此非常不鼓励单个服务器部署。

Servers	Quorum Size	Failure Tolerance
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3