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 的信息。
更具体的说:
- 如果节点B无法被对节点 A 出的探测消息进行响应,或者响应超时,它会被节点 A 标为 suspect, 如果 suspect 持续一段时间(或它收到足够多的其它节点关于B的SuspectMsg),节点A会在集群中广播SuspectMsg,告知集群中的其它节点,节点B很可疑;
- 如果B收到了针对它的 SuspectMsg,这显然是对它的不利言论,B可以通过发送 AliveMsg 告知对方, “I’m alive”。那么在对方节点看来 B 的 state 从suspect 变为 alive
- 如果一段时间内,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 *Memberli