Consul arch(四) gossip

Gossip 是一种去中心化、最终一致性的协议。

consul 使用 gossip 来管理集群节点。注意和 raft 的区别，consul 使用 raft 管理 consul servers 之间的状态同步问题，是个强一致性协议；而 gossip 则实现了 consul cluster 中所有节点发现、失效探测等状态同步问题。

注意，既然 gossip 是最终一致性，即在某个时间点，会出现节点数据不同步的情况。

consul 的 gossip 基于 serf 库 和 memberlist 库 实现 gossip。

注意，consul 中有两种 gossip pool: LAN gossip 和 WAN gossip。其中 LAN gossip 适用于同一个 Datacenter 中的节点，故 consul server 和 consul client 都会进行初始化并运行；而 WAN gossip 适用于不同 Datacenters 中的 consul servers 之间，即 consul server 相比于 consul client 会有额外的 WAN gossip 逻辑。

---

基本过程

gossip 每个节点共有 3 种状态：alive、suspect、dead

alive - 节点的正常运行状态；

suspect - 若探测某节点失败，则该节点状态在本地置为“可疑”；

dead - 当“可疑”超时后，本地会将该可疑节点转为 dead，并广播该信息；

注意，当“可疑节点”自身收到自己可疑的广播消息时，节点可以作出“反驳（refute）”，并且广播自己为 alive 的信息。

更具体的说：

1. 如果节点B无法被对节点 A 出的探测消息进行响应，或者响应超时，它会被节点 A 标为 suspect, 如果 suspect 持续一段时间（或它收到足够多的其它节点关于B的SuspectMsg），节点A会在集群中广播SuspectMsg，告知集群中的其它节点，节点B很可疑；
2. 如果B收到了针对它的 SuspectMsg，这显然是对它的不利言论，B可以通过发送 AliveMsg 告知对方, “I’m alive”。那么在对方节点看来 B 的 state 从suspect 变为 alive
3. 如果一段时间内，B 的状态仍然是 suspect, 那么对节点 A 而言，B 的状态会被置为 dead

---

这里重点关注 memberlist 库的实现。

github.com/hashicorp/memberlist/memberlist.go

func Create(conf *Config) (*Memberlist, error) {
   
    m, err := newMemberlist(conf)
    if err != nil {
   
        return nil, err
    }
    if err := m.setAlive(); err != nil {
   
        m.Shutdown()
        return nil, err
    }
    m.schedule()
    return m, nil
}

在 newMemberlist 中开始监听 tcp / udp 端口：

func newMemberlist(conf *Config) (*Memberlist, error) {
   
    // ...
    go m.streamListen()
    go m.packetListen()
    go m.packetHandler()
    return m, nil
}


// tcp 监听
func (m *Memberlist) streamListen() {
   
    for {
   
        select {
   
        case conn := <-m.transport.StreamCh():
            go m.handleConn(conn)

        case <-m.shutdownCh:
            return
        }
    }
}

// udp监听
func (m *Memberlist