本文主要对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算法。
- 所有的成员内部有一个计时器，如果在计时器归零前没有收到来自Leader的通讯，则会认为Leader已经挂了，他会自荐为Leader，并向同网络内其他成员拉票，获得高票者成为新的Leader，其他所有低票或无票的成为Follower。
- Leader会周期性的向Follower通讯，将最新的情报发送给它们，Follower也会响应本次请求（类似心跳监测）。
- 如果Leader有数据修改，Leader会先将修改日志（log entry）写在本地，然后将这次操作写入通讯，发送给Follower；Follower将修改日志同步到本机，并回应Leader。收到响应的Leader完成最终提交，否则回滚。
7.1 两种身份：
- Leader（领袖）
- Follower（跟随者）
7.2 三个阶段：
- Leader Election（领袖选举）
- Log Replication（日志拷贝）
- 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集群已经是处于不可用状态了。
网友评论