zookeeper原理（一）

一、过半机制：>n/2

  **脑裂(奇数个节点)：**
  考虑一个集群，一个机房有3台，一个机房有4台，如果两个机房网络断了，如果这时候再没有过半机制，那么这两个机房里的
  集群可能各选出一个leader，它们又开始了运行（这就叫脑裂），这时外界可能将数据存在一个集群，然后从另外的集群读取 相关的数据。
  而过半机制可以避免脑裂，但如果两机房的服务器数量一样多的话就选不出leader,但奇数个就可以

二、 领导者选举：事务id+myid

触发场景：

1）启动阶段
2）leader挂掉
3）follower挂掉，导致leader的选票低于或等于了半数

过程：

投票时，每个节点在本地都有建立一个数组，每个元素包含事务id和myid，刚开始时每个数组都只有一个元素，那就是自己的事务id+myid,然后相互交流决定把自己的票投给谁（具体交流的流程不清楚），规则是先比较事务id，小的将它的票投给大的，如果相同则比较myid(myid是手动设置的每个node都不一样)

事务id:

  事务：对数据的增删改等
  非事务：对数据的读等
  越新的事务操作其id越大

三、两阶段提交：

写请求流程：

当用户向leader发送了一个写请求后，leader首先向follower们发送预提交请求，follower如果将要进行的写操作日志存储下来了，就向leader发送ack回答，当leader收到超过一半的回答后，它就向follower发送commit请求，当follower收到后，就会将已经存储下来的日志恢复到datatree中如果用户向follower发送了一个写请求，follower会将该请求发送给leader，然后leader再执行。

读请求流程

如果用户发送的读请求，无论follower还是leader直接读就好了

	这里有个有意思的地方，如果想提高写的性能，那么减少follower的数量，但同时读的性能就降低了，反过来，为了提高读的
	性能而增加follower的数量，写的性能便会降低。从而引出 提高读请求性能：观察者模式observer

zookeeper选举流程（代码级别）：

选举逻辑：

本节点从recvQueue中获取一张来自其他节点的选票，然后与自己的选票（初始时是 投自己）进行比较，如果自己的选票大仍坚持自己的选票,反之将自己的选票修改为另一张选票建议的节点，然后丢给queueSendMap，让它将其发给其他节点。同时每个节点都有一个map用于存放其他节点的获得的投票，key为票的来源节点，所以这样当一个节点更新它的投票后，通过相同key值的覆盖，便能保证每个节点只有投一张票的权利。每当本节点修改自己的投票后，都会检查自己刚投的那个节点的票数是不是获得了超过一半的票数，如果是则进入一个while循环，查看recvqueue里是否还有比准leader节点的票更大的，如果有退出循环重新继续进行投票等流程，如果没有，则将自己状态从looking设置为following或leading,同时将current变量设置为leader节点。如果再有其他节点将投票发给这个节点，无论哪个大，该节点都会把current的信息和自己状态返回给另一个节点，那个节点收到返回的投票后，发现投票者的状态已经不是looking了，那么便会根据返回的投票把自己设置为follower或leader，同时设置自己的current为leader的信息。这样便能选出一个leader了。

1）queueSendMap:
用于存储产生的选票，以sid(被投票的主机id)为key,每张选票都有一个sendWorker将其发送给其他node
2）recvQueue
:由recvWorker线程（只有一个）接收到的来自其他节点的选票
3） sendWorker：
4）RecvWorker：
5）listener：
以配置文件的第二个端口来监听来自其他主机的投票，初始化时并没有为其与所有主机建立socket连接，而是在刚开始从选票箱取选票时发现并没有选票，这时候才会为它与其他主机建立socket连接，但是会根据某个值让该值较大的主动建立连接从而避免了两个主机通信建立了两个socket连接，因为socket连接是全双工的，所以一个就足够了。至于为什么延迟建立socket连接，是因为节点处于looking状态时便会触发选举对应初始化方法，但是observer节点是不会 参与投票竞争的，所以它是没有必要建立socket连接参与投票。
6）选票箱：

补充：

zookeeper内存维护dataTree,事务操作持久化为日志文件，当日志文件超过某个阀值时，会将dataTRee快照于磁盘镜像，同时删除其之前的对应的日志文件