Consul中的概念（施工中）

本文主要对Consul中的几个概念进行了归纳和梳理，为方便后续使用。

1. RPC（远程过程调用）

RPC是「服务器A」调用在「服务器B」上的服务这么一个操作。

---

2. Datacenter（数据中心）

Datacenter是一个私有、低延迟和高带宽的网络环境。

下文简称DC。

---

3. Agent（代理）

Agent是一直运行在节点上的守护进程。

3.1 Type（类型）：

Agent按照类型区分，可划分为Server和Client。

3.1.1 Server（服务端）：

• 功能：负责领袖选举（见7），维护集群状态，响应RPC查询，与其他DC交互WAN gossip转发查询给Leader节点或者远程DC等。
• 数目：每个DC中至少有一个Server。
• 注意：Server不直接接收RPC请求。

3.1.2 Client（客户端）：

• 功能：负责注册服务，运行健康检查，转发RPC请求到Server。
• 数目：每个DC中建议有3-5个Client。

Client是相对无状态的，Client唯一执行的后台活动是加入LAN gossip池。这里有一个最低的资源开销，并且消耗少量的网络带宽。

---

4. Node (节点)

Node是DC中的一个成员（服务器）。

每个Node都必须运行Agent，可以粗略地将Node和Agent划等号。

4.1 Identity（身份）：

正常情况下节点按身份分，可划分为Leader和Follower；
但当Leader挂掉以后，consul会启动选举机制，产生一个新的Leader，此时走完一个监听流程的节点成为Candidate，并为自己拉票。

工作流程：首先选举出第一任Leader，全权负责管理日志复制。Leader从客户端接收log entries，将它们复制给同一DC中的其他Follower，然后告诉Follower什么时候将日志应用于它们的状态机。

• Leader可以不过问Follower的情况下，决定把新entries放在哪个位置。
• 数据永远是从Leader流向Follower。
• Leader可以Fail或者与其他机器失去连接，这种情形下会有新的Leader被选举出来。

4.1.1 Leader（领袖）：

• 功能：Leader节点会将数据同步到Follower节点；
• 限制：一个DC中有且只有一个Leader
• 补充：Consul默认只有领袖对请求进行响应，所有对追随者的请求将被转发给领袖。在有大量请求的大型集群中,这显得不够有扩展性（可以通过max_stale修改）。

4.1.2 Follower（跟随者）：

默认情况下Follower不会主动发起RPC消息。

4.1.3 Candidate（候选者）：

等待推举为Leader的状态。

4.2 Status（状态）：

Node的状态有两种，分别是Healthy和Unhealthy。

4.2.1 Healthy（健康）：

可用

4.2.2 Unhealthy（非健康）：

不可用

---

5. Consensus（一致性）

Consensus就是逻辑上对于被选举出的leader以及事物的顺序的认同

---

6. Gossip

Gossip协议是让所有的通信节点最终达成一致的协议。

6.1 概念：

Gossip算法又被称为反熵（Anti-Entropy），熵是物理学上的一个概念，代表杂乱无章，而反熵就是在杂乱无章中寻求一致。

在一个有界网络中，每个节点都随机地与其他节点通信，经过一番杂乱无章的通信，最终所有节点的状态都会达成一致。要注意到的一点是，即使有的节点因宕机而重启，有新节点加入，但经过一段时间后，这些节点的状态也会与其他节点达成一致，也就是说，Gossip天然具有分布式容错的优点。

Gossip是一个带冗余的容错算法，更进一步，Gossip是一个最终一致性算法。

6.2 特性：

• Gossip使用基于UDP的随机的点到点通信。

• Consul建立在Serf的基础之上，它提供了一个用于多播目的的完整的gossip协议。Serf提供成员关系，故障检测和事件广播。

• 同一个DC的所有节点都必须加入gossip协议。这意味着Gossip协议包含一个给定数据中心的所有节点。这服务于几个目的：

  a. 不需要在client上配置server地址。发现都是自动完成的。
  b. 检测节点故障的工作不是放在server上，而是分布式的。这使得故障检测相比心跳机制有更高的可扩展性。
  c. 它用来作为一个消息层来通知事件，比如leader选举发生时。

6.3 实现

Consul使用两个不同的gossip池。我们分别称为WAN池和LAN池。

6.3.1 WAN gossip

• 目的：WAN池提供的成员关系允许Server执行跨数据中心请求。集成的故障检测允许Consul优雅的处理整个数据中心失联。
• 数目：全局唯一。
• 包含：WAN池包含且只包含整个Consul集群内的所有Server节点。

6.3.2 LAN gossip

• 目的：成员关系使得Client自动发现Server，减少配置量；分布式的故障检测允许故障检测的工作由整个集群承担，而不是集中在少数Server上；gossip池允许可靠和快速的事件广播，比如Leader选举。
• 数目：每个DC都有一个LAN gossip池。
• 包含：LAN池包含它所在DC内的所有Client和Server。

7. Raft

一句话：Raft是一种算法，能实现分布式的意见一致性，参考《一则动画了解Raft》。

Consul使用Raft算法来保证一致性。
Consul中只有以Server模式运行的节点，才会被认为是Raft节点集的一部分。
下文仅做简略介绍，届时另开一文详细解释Raft算法。

1. 所有的成员内部有一个计时器，如果在计时器归零前没有收到来自Leader的通讯，则会认为Leader已经挂了，他会自荐为Leader，并向同网络内其他成员拉票，获得高票者成为新的Leader，其他所有低票或无票的成为Follower。
2. Leader会周期性的向Follower通讯，将最新的情报发送给它们，Follower也会响应本次请求（类似心跳监测）。
3. 如果Leader有数据修改，Leader会先将修改日志（log entry）写在本地，然后将这次操作写入通讯，发送给Follower；Follower将修改日志同步到本机，并回应Leader。收到响应的Leader完成最终提交，否则回滚。

7.1 两种身份：

1. Leader（领袖）
2. Follower（跟随者）

7.2 三个阶段：

1. Leader Election（领袖选举）
2. Log Replication（日志拷贝）
3. Commit(提交修改)

7.3 三种一致性模式：

7.3.1 Default（基于Leader约期）

• 概括：牺牲强一致性，保障了读的效率。
• 解析：Raft算法默认使用了Leader约期的概念：在一个时间窗口中，Leader认为自己的角色是稳定的。
• 极端情况：如果Leader节点与别的节点被分隔（参考动画中Log Replication中add partition环节），即发生所谓“脑裂”现象，那么会有一个新的Leader节点被选举出来（此时同一个网络中存在两个Leader）。此时原Leader节点将不能提交任何新的log entry（因为它无法获得绝大多数成员的响应）；如果它提供了对数据的读取，那么Client读可能读到过期值。

思考：动画例子中提供的是「1台Leader+1台Follower」和「1台Leader+2台Follower」的例子，集群会默认接收2台Follower的为有效Leader。如果是同等数量的两个部分，会是怎样？

7.3.2 Consistent（一致性）

• 概括： 牺牲读的速度，保障了强一致性。
• 解释：这种模式是强一致性模式。这种模式要求Leader节点，每次做读和写操作时都要与法定个数的节点去确认自己仍然是Leader。

7.3.3 Stale（脏读）

• 概括： 牺牲一致性，保证了最高速的读效率。
• 解析：这种模式允许任何Consul Server向外部提供读取操作，无论它是不是Leader节点。 这种模式特别快，但是读到过期数据的可能性非常大。这种模式允许在没有Leader节点的情况下对读请求做出相应，尽管实际上这时候Raft集群已经是处于不可用状态了。

参考资料

1. Consul官方网址
2. Gossip协议
3. 《Consul实现原理系列文章1:用Raft来实现分布式一致性》
4. 《分布式一致性之Raft算法》