Consule系列:Consul实现详解

Consul 使用 Consensus 协议提供一致性(Consistency)—— CAP 定义的一致性。Consensus 协议是基于 “Raft: In search of an Understandable Consensus Algorithm” 实现的。

Consul Protocol

Raft 算法

• Raft 是基于 Paxos 的一致性算法。 与 Paxos 相比，Raft 被设计为具有更少的状态和更简单，更容易理解的算法。
• Raft 算法是一种基于日志复制实现数据同步的高效算法，它在解决分布式系统中各个节点记录内容一致性问题的同时，也使得集群具备一定的容错能力。这种容错能 力体现在两个方面。
  • 当集群中出现网络故障或少于半数节点发生故障时，仍可以保证其余大多数节点正运行 。
  • 当集群中超过半数节点出现故障时 ，将导致集群不可用，但 Raft 算法依然可以保证节点中的数据不会出现错误的结果，从而为集群提供灾后备份和恢复的机会。

Raft 术语

• Log:在 Raft 系统主要的工作单元为 Log entry。一致性的问题可以分解为复制日志。一个 log 是一个顺序的条目列表(entrylist)。如果所有成员都同意 log 的entry 和顺序，我们认为日志是一致的。
• FSM:有限状态机。FSM 是有限个状态的集合以及在这些状态之间的转移和动作等行为的数学模型。当应用新日志时，允许 FSM 在状态之间转换。 相同的日志序列的应用必须导致相同的状态，这意味着行为必须是确定性的。
• Peer set:Peer set 是参与日志复制的所有成员的集合。对于 Consul 而言，所有的 server 节点 均属于本地数据中心的 Peer set。
• Quorum:法定票数，取决于 Peer set 大多数成员。对于大小为 n 的 set，quorum 需要至少(n / 2)+1 个成员。例如，Peer set 有 5 个 server 节点，就需要 至少 3 个节点才能形成 quorum。无论什么原因，只要 quorum 是无效的，那么 cluster 就会变为 unavailable，并且不会再有 log 提交。
• Committed Entry:当条目永久存储在在法定数量的节点上，该条目才会被视为已提交(committed)。 一旦条目提交，它可以被应用。
• Leader:在任何给定的时间，Peer set 选举一个节点作为 Leader。当 log commited 时，Leader 负责新 entry 处理、复制到 Followers，以及管理何时 entry 被视为已提交。

Raft 角色和状态机

Raft 集群中的每个节点都处于一种基于角色的状态机中。具体来说， Raft 定义了节点的三种角色:Follower、Candidata 和 Leader。

• Leader(领导者):Leader 节点在集群中有且仅能有一个，它负责向所有的 Follower 节点同步日志数据。
• Follower(跟随者):Follower 节点从 Leader 节点获取日志，提供数据查询功能，并将所有修改请求转发给 Leader 节点。
• Candidate(侯选者):当集群中的 Leader 节点不存在或失联后，其它 Follower 节点转换为 Candidata，然后开始新的 Leader 节点选举。

在节点初始启动时，所有节点的 Raft 状态机均处于 Follower 状态。当 Follower 在一定时间周期内没有收到来自 Leader 节点的心跳数据包时，节点会将自己的状态切换为 Candidate，并向集群中其它 Follower 节点发送投票请求，Follower 都会将自己的票投给收到的第一个投票请求节点。当 Candidate 收到来自集群超过半数节点的接收投 票后，即成为新的 Leader 节点。Leader 节点将接收并保存用户发送的数据，并向其它的 Follower 节点同步日志。

Leader 节点依靠定时向所有 Follower 发送心跳数据包来保持其地位。当集群中的 Leader 节点出现故障失联时，Follower 中又会重新选举出新的节点，从而确保整个集群 正常运作。

每成功选举一次，新 Leader 的 Team(任届)值都会比之前 Leader 的增加 1。当集群中由于网络或其它原因的故障出现分裂又重新合并时，集群中可能会出现多于一个的 Leader 节点，此时，Term 值更高的一个节点将成为真正的 Leader。

Raft in Consul

只有 Consul server 节点参与 Raft，并且组成 Peer set。 所有 clients 节点将请求转发到 server 节点。 此设计的部分原因是，随着更多成员被添加到 Peer set，法定票 数(quorum )的大小也随之增加。 这就引入了性能问题，因为您可能正在等待数百台机器同意一个 entry，而不是少数。

开始时，单个 Consul 服务器被置于 bootstarp(引导) 模式，且在“一个 Datacenter 中 只能有一个 server 节点 处于 bootstrap 模式(多 bootstrap 模式的 server 会 使群集处于不一致的状态)，当一个 server 处于 bootstrap 模式时，可以选举自己为 raft leader。一旦 lender 被选举，其他 server 节点可以以保持一致性和安全性的方 式添加到集群中。最终，一旦添加了指定数目的(-bootstrap-expect`选项指定)server 节点后，那么就可以禁用第一个节点的 “bootstarp” 模式。

Consistency Modes

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

• Default-Raft
  • 采用 Leader 租赁模式，提供了一个时间窗口，在该时间段内， Leader 角色是稳定的。但是，如果 Leader 从 Peers set 分裂出去，新的 Leader 就可能选举 出来，而旧 Leader 持有租赁。这意味着有 2 个 leader 节点。因为旧 Leader 不能提交新日志，就没有脑裂的风险。然而，如果旧 Leader 执行任何读取操 作，其读取到的结果就可能是过期的。Default 一致性模式只依赖于 Leader 租赁，Client 可能使用过期的数据。之所以这么权衡，因为读取是快速的，通常是 采用强一致性模式，只有在一个难以触发的情况下过期。并且时间窗口也是有界的，时间到了，leader 也会下台。
• consistent
  • 这种模式是无条件一致性。它要求 leader 必须与 quorum 个 Peer 校验，虽然它仍然是 Leader。这将引入额外的节点轮询，增加了延迟。采用一致性读取，会导致额外的轮询开销。
• stale
  • 这种模式允许在任何 Server 节点执行读取操作，无论它是不是 Leader。这意味着可能读取到旧的数据，但一般而言，速度与 leader 相比差距在 50 毫秒内。
  • 这种方式，读取速度是非常快的，但可能是旧的数据。这种模式下，即使没有 Leader，一样可以相应读取操作。