常见集群算法解析

Gossip协议

Gossip协议简介

定义

Gossip protocol，又叫 Epidemic Protocol （流行病协议），也叫“流言算法” 、 “疫情传播算法”等。其名称已经形象的说明了算法的原理和工作方式

应用场景

1. 分布式网络，无集中管理节点
2. 节点间点对点传播信息

典型应用

1. P2P
2. Bitcoin
3. Apache Cassandra、Redis cluster

Gossip协议优缺点

优点

简单

1. 扩展性：网络节点可随意增加和修改
2. 容错性：无中心节点，任意节点宕机不影响协议运行
3. 去中心化：任意节点都可以发送消息

缺点

最终一致性

1. 需要花费一定时间达到最终一致性
2. 消息冗余
3. 不适合超大规模集群（超过1000）
4. 恶意节点传播垃圾信息

Gossip模式

模式1-Direct Mail

直邮模式：通知所有邻居更新信息，邻居节点收到消息后不会转发

优点

简单

缺点

1. 难以达到最终一致性
2. 节点消息可能丢失（图中黄色节点）
3. 节点可能并没有连接（图中深红色节点）
4. 容错性低
5. 需要缓存发送失败的消息
6. 种子节点压力大

应用场景

社交网络（朋友的朋友并不一定是你的朋友）

模式2-Anti-Entropy

反馈模式：集群中的节点，每隔一段时间随机选择1个节点，互相交换所有数据，然后进行同步，消除数据不一致

优点

最终一致性

缺点

1. 信息同步的成本高
2. checksum
3. updated list
4. 达到最终一致性的耗时较长

应用场景

节点数量不多，实现最终一致性，例如存储系统多副本一致性

模式3-Rumor mongering

谣言传播：收到更新消息后，自己成为“受感染节点”，周期性的传播更新消息，如果发现其他节点已经知道了消息，则按照一定概率将自己变为removed，不再传播消息

优点

1. 最终一致性
2. 传播信息少
3. 达到一致性所需时间少

缺点

1. 有一定概率可能不一致
2. 节点数量不能太多，Redis官方文档最大1000

应用场景

节点经常变化的集群

Bully选举算法

Bully算法简介

Bully算法

当一个进程发现协调者（或 Leader）不再响应请求时，就判定其出现故障，于是它就发起选举，选出新的协调者，即当前活动进程中进程号最大者

Bully 的中文意思是“霸凌” ，但实际实现的时候，找最小的节点也可以，关键点在于“最”

关键假设

1. 系统是同步的
2. 进程在任何时候都可能失败，包括算法在执行的过程中
3. 进程失败后停止工作，重启后重新工作
4. 有失败监控者，它可以发现失败的进程
5. 进程之间消息传递是可靠的
6. 每一个进程知道自己和其他每一个进程的 ID 以及地址

Bully算法选举过程

step0：初始状态，P6为Leader

step1：P6故障

step2：P3 检测到 P6 故障，发起选举，向 P4、P5、P6 发送 Election 消息

step3：P4、P5 回复 P3 Alive 消息，说明自己还活着，P3 退出选举，等待 Victory 消息

step4：P4向P5、P6发送 Election 消息

step5：P5回复P4 Alive 消息，P4退出选举，等待 Victory 消息

step6：P5向P6发送 Election 消息

step7：P5未收到 Alive 消息，成功当选，向所有节点发送 Victory 消息，选举结束

Raft选举算法

Raft算法简介

Raft算法

Raft is a consensus algorithm that is designed to be easy to understand. It’s equivalent to Paxos in fault-tolerance and performance. The difference is that it’s decomposed into relatively independent subproblems, and it cleanly addresses all major pieces needed for practical systems

关键点

1. 容易理解
2. 算法明确划分为选举、复制、安全三个子问题

Raft实现

实现1-leader选举

1. The client of the application makes requests only to and gets responses only from the leader server
2. only be available when a leader has been successfully elected and is alive

实现2-日志复制

State machine replication：复制状态机，复制的是命令而不是数据，典型代表：Raft

Primary-backup system：主备复制，复制的是命令执行后的数据，典型代表：Zookeeper的ZAB

两者差别：是否能够容忍“非拜占庭错误”

Raft的实现

每个节点都有一个状态机和一致性模块，由一致性模块保证分布式一致性，节点之间复制的是 client 发送的命令，无论读写请求都需要进行一致性处理，因此可以容忍非拜占庭故障

Raft vs ZAB vs Paxos

	Raft	ZAB	Paxos
分布式一致性	弱于Paxos	弱于Paxos	最强
复制方式	State machine replication	Primary-backup system	State machine replication
读写方式	读写leader，follower不接受请求	读写leader，读follower	任意节点都可以读写
是否有leader	是，强leader	是，强leader	无，部分变种有Leader，但只是协调作用
复杂度	比Paxos简单	比Paxos简单	复杂
特殊场景	选举期间不能服务	选举期间不能服务	Livelock

Raft vs Zookeeper

1. 如果你想内嵌分布式选举或者一致性功能，或者基于业务特性做一些小调整，选择Raft，例如MongoDB、etcd等
2. 如果你想实现分布式选举或者一致性，但是不想自己去实现协议代码，选择Zookeeper，例如HDFS、Cassandra等
3. 如果你不确定，请选择Zookeeper

Raft的资源