一个分布式服务集群管理通常需要一个协调服务,提供服务注册、服务发现、配置管理、组服务等功能,而协调服务自身应是一个高可用的服务集群,ZooKeeper是广泛应用且众所周知的协调服务。协调服务自身的高可用需要选举算法来支撑,本文将讲述选举原理并以分布式服务集群NebulaBootstrap的协调服务NebulaBeacon为例详细说明协调服务的选举实现。
为什么要选NebulaBeacon来说明协调服务的选举实现?一方面是我没有读过Zookeeper的代码,更重要的另一方面是NebulaBeacon的选举实现只有两百多行代码,简单精炼,很容易讲清楚。基于高性能C++网络框架Nebula实现的分布式服务集群NebulaBootstrap是一种用C++快速构建高性能分布式服务的解决方案。
为什么要实现自己的协调服务而不直接用Zookeeper?想造个C++的轮子,整个集群都是C++服务,因为选了ZooKeeper而需要部署一套Java环境,配置也跟其他服务不是一个体系,实在不是一个好的选择。Spring Cloud有Eureka,NebulaBootstrap有NebulaBeacon,未来NebulaBootstrap会支持ZooKeeper,不过暂无时间表,还是首推NebulaBeacon。
1. 选举算法选择
Paxos算法 和 ZooKeeper ZAB协议 是两种较广为人知的选举算法。ZAB协议主要用于构建一个高可用的分布式数据主备系统,例如ZooKeeper,而Paxos算法则是用于构建一个分布式的一致性状态机系统。也有很多应用程序采用自己设计的简单的选举算法,这类型简单的选举算法通常依赖计算机自身因素作为选举因子,比如IP地址、CPU核数、内存大小、自定义序列号等。
Paxos规定了四种角色(Proposer,Acceptor,Learner,以及Client)和两个阶段(Promise和Accept)。 ZAB服务具有四种状态:LOOKING、FOLLOWING、LEADING、OBSERVING。 NebulaBeacon是高可用分布式系统的协调服务,采用ZAP协议更为合适,不过ZAP协议还是稍显复杂了,NebulaBeacon的选举算法实现基于节点的IP地址标识,选举速度快,实现十分简单。
2. 选举相关数据结构
NebulaBeacon的选举相关数据结构非常简单:
const uint32 SessionOnlineNodes::mc_uiLeader = 0x80000000; ///< uint32最高位为1表示leader
const uint32 SessionOnlineNodes::mc_uiAlive = 0x00000007; ///< 最近三次心跳任意一次成功则认为在线
std::map<:string uint32> m_mapBeacon; ///< Key为节点标识,值为在线心跳及是否为leader标识
如上数据结构m_mapBeacon保存了Beacon集群各Beacon节点信息,以Beacon节点的IP地址标识为key排序,每次遍历均从头开始,满足条件(1&&2 或者 1&&3)则标识为Leader:1. 节点在线;2. 已经成为Leader;