在互联网的高速发展下，如果服务器不使用个集群模式，自己都不好意思出去面试。目前所知的大部分集群模式都是基于中心化思想来部署，而中心化的思想是建立在服务器选举Leader规则之上，著名的一致性算法Raft可以实现集群的选举工作，不过Raft算法也不是一般程序员可以掌握的。
集群的选举主要是为了能让集群正常工作，在不使用Raft等复杂算法的前提下，能否可以搞定集群的选举工作呢？当然可以，不过要借助其他技术，今天就来说一说，如何利用zookeeper来搞定集群选举Leader的工作。
01
PART
Zookeeper
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
Zookeeper的节点类似于UNIX文件系统，是一个简单目录树结构的数据模型，在这棵树中，每个节点都可以作为一个ZNode，每一个ZNode都可以通过唯一路径来标识
临时性节点
在Zookeeper中，节点（ZNode）分为几个类型，其中有一个类型为临时性节点，它有个特点：它的生命周期和创建这个节点的客户端Session绑定，一旦这个客户端掉线或者down机，这个节点就会自动删除。
Watch
Zookeeper提供了节点变化通知机制，即Watch机制。每个客户端可以选择任意的节点进行监听，如果被监听的节点或者子节点发生变化，便会通知所有监听的客户端，基于这个原理就能实现集群服务器的自动发现机制。
集群的选举
一个分布式的集群服务，最重要的就是不间断的提供服务，或者说是容错性。当一个节点由于故障原因退出集群或者一个新节点加入集群，不会影响集群的服务能力。当Leader节点出现故障，能实现自动选举功能，而不用人工干预，那利用Zookeeper怎么做到呢？
首先必须要有几个约定：
- 所有的集群服务器监听相同的Zookeeper节点，这个节点充当集群信息的存储
- 集群中的服务器可以利用ip或者机器名作为节点名称，不允许有重复的节点名称
- 集群默认采用名称排序最小的服务器作为Leader
具体的过程如下：
- 当集群的第一个服务器启动，注册自己的信息到Zookeeper固定节点下，并监听此节点的变化。发现只有自己一个服务器，则默认当选Leader。
- 当其他服务器启动并注册信息到相同节点下，并监听此节点信息变化。发现已经有Leader，默认作为follower进行工作。
- 当Leader由于故障掉线，信息会自动从Zookeeper删除，其他节点会收到通知，然后把Leader节点踢除，进入下一个Leader选举流程。
- 存活的服务器中，根据约定，名字最小的服务器当选Leader，并向其他服务器发送通知，这个时候集群可以继续正常工作。
- 如果是非Leader节点掉线，流程和以上类似，但是少了选举的过程。
就算是在选举过程中持续有客户端掉线也没有关系，因为Zookeeper能保证最终的数据一致性，在加上我们约定的名字最小的为Leader的约束，最终集群的状态将达到稳定。
这里提出一个新问题，利用Zookeeper来进行集群的选举，会不会出现脑裂问题呢？
