Nomad技术手册：共识协议（Consensus Protocol）

最新推荐文章于 2024-08-22 17:26:02 发布

zl1zl2zl3

最新推荐文章于 2024-08-22 17:26:02 发布

阅读量3.5k

点赞数 1

分类专栏： raft hashicorp nomad 一致性协议 hashicorp产品文章标签： hashicorp nomad 协议一致性

协议同时被 3 个专栏收录

54 篇文章 0 订阅

订阅专栏

hashicorp

30 篇文章 2 订阅

订阅专栏

nomad

19 篇文章 5 订阅

订阅专栏

Nomad使用共识协议来提供一致性(由CAP定义)。共识协议的基础是“Raft:寻找一种可以理解的共识算法”。有关Raft的可视化解释，请参见数据的秘密生命。

高级主题!这个页面涵盖了Nomad内部的技术细节。您不需要知道这些细节就可以有效地操作和使用Nomad。对于那些希望了解这些细节而不需要通过源代码进行深入研究的人来说，这些细节在这里都有文档说明。

Raft 协议概观

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

在讨论Raft时，有几个关键术语需要知道:

日志 - Raft系统的主要工作单元是日志条目。一致性问题可以分解为一个复制日志。日志是条目的有序序列。如果所有成员都同意条目及其顺序，我们就认为日志是一致的。
FSM - 有限状态机。FSM是有限状态和它们之间的转换的集合。在应用新日志时，允许FSM在状态之间进行转换。应用相同的日志序列必须导致相同的状态，这意味着行为必须是确定性的。
对等组 - 对等组是参与日志复制的所有成员的集合。对于Nomad来说，所有服务端节点都位于本地区域的对等节点组中。
法定人数 - 法定人数的大部分成员从一个对等组:一组大小n,法定人数至少需要⌊(n / 2)+ 1⌋成员。例如，如果对等组中有5个成员，则需要3个节点来形成仲裁。如果由于任何原因，节点数量不可用，则集群不可用，并且不能提交新的日志。
提交条目 - 当条目持久存储在法定人数上的节点时，就认为提交了条目。一旦提交了一个条目，就可以应用它。
领导者 - 在任何给定的时间，对等组只能选择某一个节点作为领导者。领导者负责吸收新的日志条目，复制到追随者中，并在认为提交了一个条目时进行管理。

Raft是一种复杂的协议，不会在这里详细介绍(对于那些希望得到更全面了解的人，此文提供了完整的规范)。然而，我们将试图提供一个高层次的描述，这可能对构建心理模型有用。

Raft节点总是处于以下三种状态之一:追随者、候选人或领导者。所有节点一开始都是追随者。在这种状态下，节点可以接受来自领导者的日志条目并进行投票。如果在一段时间内没有收到条目，节点会自动提升到候选人状态。在候选人状态中，节点请求同伴的投票。如果一位候选人获得法定人数的选票，那么他就被提升为领导者。领导者必须接受新的日志条目，并复制到所有其他追随者。此外，如果不能接受陈旧的读取，所有查询也必须在领导者上执行。

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

在法定人数可用的范围内，共识是容错的。如果节点法定人数不可用，则不可能处理日志条目或考虑对等成员关系。例如，假设只有两个对等节点:A和b。法定人数也是2，这意味着两个节点必须同意提交一个日志条目。如果A或B失败，现在就不可能达到法定人数。这意味着集群无法添加或删除节点或提交任何其他日志条目。这导致了不可用。此时，需要手动干预以删除A或B，并在引导模式下重新启动剩余节点。

3个节点的Raft集群可以容忍单个节点故障，而5个节点的集群可以容忍2个节点故障。建议的配置是每个区域运行3个或5个Nomad服务器。这可以在不牺牲性能的情况下最大化可用性。下面的部署表总结了可能的集群大小选项和每个选项的容错。

就性能而言，Raft与Paxos类似。假设具有稳定的领导能力，提交日志条目需要往返于集群的一半。因此，性能受磁盘I/O和网络延迟的限制。

Nomad中的Raft

只有Nomad服务端节点参与到Raft中，并且是对等组的一部分。所有的客户端节点将请求转发给服务端。Nomad中的客户端只需要知道它们的分配并从服务端查询该信息，而服务端需要维护集群的全局状态。

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

由于Raft复制的特性，性能对网络延迟很敏感。因此，每个区域选择一个独立的领导者并维护一个独立的对等组。数据按区域划分，所以每个领导者只对其区域中的数据负责。当接收到远程区域的请求时，将该请求转发给正确的领导者。这种设计允许更低的延迟事务和更高的可用性，而不会牺牲一致性。

一致性模式

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

这两种读取模式是:

默认模式 - Raft利用领导者租约，提供了一个时间窗口，让领导者扮演稳定的角色。然而，如果一个领导者从其他领导者中分离出来，新领导者可能会被选举出来，而老领导者则会持有租约。这意味着有两个领导者节点。不存在脑裂的风险，因为以前的领导者将无法提交新的日志。但是，如果以前的领导者为任何读取提供服务，那么这些值可能已经过时了。默认的一致性模式仅依赖于领导者租约，将客户端暴露在潜在的旧值中。我们之所以这样做，是因为读起来很快，通常非常一致，而且只在难以触发的情况下才会过时。陈旧读取的时间窗口也是有限制的，因为领导者将因为分区而退休。
陈旧模式 - 这种模式允许任何服务端为读服务，而不管它是否是领导者。这意味着读取可以任意陈旧，但通常在领导者的50毫秒内。这种权衡是非常快速和可伸缩的读取，但是使用陈旧的值。这种模式允许在没有领导者的情况下读取，这意味着不可用的集群仍然能够响应。