Leader Election
Zookeeper的基本操作
Zookeeper虽然是分布式系统，但它并不是为文件存储而设计的，Zookeeper里存储的一般是配置信息和源信息。实际上，Zookeeper在每个节点上存储大小都在1M一下（通常是远小于1M）
基于Zookeeper的Leader Election
抢注Leader节点——非公平模式
1.创建Leader父节点，如/chroot，并将其设置为persist节点
2.各客户端通过在/chroot下创建Leader节点，如/chroot/leader，来竞争Leader。该节点应被设置为ephemeral
3.若某创建Leader节点成功，则该客户端成功竞选为Leader
4.若创建Leader节点失败，则竞选Leader失败，在/chroot/leader节点上注册exist的watch，一旦该节点被删除则获得通知
5.Leader可通过删除Leader节点来放弃Leader
6.如果Leader宕机，由于Leader节点被设置为ephemeral，leader节点会自行删除除。而其它节点由于在Leader节点上注册了watch，故可得到通知，参与下一轮竞选，从而保证总有客户端以Leader角色工作
先到先得，后则监视前者——公平模式
1.创建Leader父节点，如/chroot。并将其设置为persist节点
2.各客户端通过在/chroot下创建Leader节点，如/chroot/leader，来竞争Leader。该节点应被设置为ephemeral_sequential
3.客户端通过getChildren方法获取/chroot/下所有子节点，如果其注册的节点的id在所有子节点中最小，则当前客户端竞选Leader成功
4.否则，在前面一个节点上注册watch，一旦前者被删除，则它得到通知，返回step3
5.Leader节点可通过自行删除自己创建的节点以放弃Leader
Leader Election在Curator中实现（Curator提供2种实现）
Kafka基于Controller的Leader Election
基于Controller的Leader Election
》整个集群中选举出一个Broker作为Controller
》Controller为所有的Topic的所有Partition指定Leader及Follower
优点
》极大缓解Herd Effect问题
》减轻Zookeeper负载
》Controller与Leader及Follower间通过RPC通信，高效且实时
缺点
》引入Controller增加了复杂度
》需要考虑Controller的Failover
注：Kafka 0.8.2之前的版本Kafka的Leader Election是由每个Patition的多个Replica同时竞争Leader。
接下来我们讲讲Kafka Controller，下面是Kafka的一部分源码，主要是讲Controller
//每个server启动起来之前都要先启动kafkaController
我们进去看看
//这部分功能是监控eclectionPath，也就是Controller的Path，观察是否有数据变化
//如果有数据变化，就进入elect函数，立马做一次选举
我们看怎么选举的
//不管当前有没有Controller,先获取leader信息，再去判断Controller是否是leader
Controller Failover
Controller挂了，如果Controller是leader，那么新的Controller会告诉所有的和leader有关的follower新的leader，通过RPC的方式。
