分布式系统心跳机制（一）

本文分享自天翼云开发者社区《分布式系统心跳机制（一）》，作者:白杨

分布式系统架构

当前大部分分布式系统架构如下图：

有一个中心节点来存储集群元数据和管理 work 儿节点，中心节点采用主备模式来实现 HA。当中心节点主故障后，备节点接管业务成为主节点。我们下面讨论的心跳机制就是基于这种分布式架构而设计的。

心跳设计目标：

1.master 控制节点的切换，不可以影响 server 的心跳。

2.server 可以感知到 master 的每一次切换。

3.master 在任意场景下都不会丢失 server 故障的事件。

4.心跳可以作为其它控制消息是否需要重试的依据。

心跳 Clien 端设计：

a.worker2 启动后只有 master 的列表，并不知道哪个是 leader，因此先广播 bootstrap 信息。

b.只有 leader 节点响应 bootstrap 信息，leader 生成 session id 并持久化，返回 bootstrap ack 给 worker2，标记 worker2 为 Up。

c.worker2 收到 ack 信息本地记录 leader 的 epoch，sessionid 等信息作为后续发送心跳的凭证，并进入 connected 状态。

d.bootstrap ack 消息还需要携带，心跳超时时间，假心跳超时时间。

假心跳超时：假心跳超时的时间一般小于心跳超时的时间，例如：心跳超时的时间为 5s，假心跳超时的时间就为 3s。这主要是为了识别 leader 切换，当到了假心跳超时时间后，worker 将开始广播心跳，尝试连接到新的 leader，在心跳超时时间内连接上新的 leader 则对外是无感知的。

a.worker2 进入 connected 状态后，后续定期发送 HB 消息给 leader，leader 返回 ACK。

b.如果这时候 leader 故障了，follwer 变成 leader，超过假心跳超时时间后将会触发心跳广播。

a.leader 故障后，新的 leader 接管了业务，并且从持久化存储中 load 起 worker2 的相关信息，主要是 sessionid 信息。

b.worker2 到达假心跳时间后意识到旧 leader 可能故障，因此开始广播心跳寻找新的 leader。

c.新的 leader 收到 worker2 的信息，并且比对 sessionid 是一致的则接收并返回 hb ack。

d.worker2 收到新的 HB ack 后更新新的 leader 地址与 epoch 信息，整个流程对外是透明的。

a.worker2 找到新 leader 后，不再广播心跳而是单一的给 leader 发送。