|
zookeeper本身是一个分布式应用程序，为写入分布式应用程序提供服务 一般提供常见的服务有：命名服务，配置管理，集群管理，分布式锁，分布式锁
命名服务：在zokeeper的文件系统里创建要给目录，就会有唯一的path。 在我们使用 tborg无法确定上游程序的部署机器与下游程序约定好path，通过path就能互相探索发现。
配置管理：如果程序分散部署在多台机器上，要逐个改变配置就变得困难。 如果把这些配置全部放到zookeeper中，保存在某个目录节点中，然后所有相关 程序对这个目录节点进行监听， 一旦配置信息发生变化，每个应用程序就会收到zookeeper通知，然后从zookeeper获取新的配置信息应用到系统中。
zookeeper集群管理：主要有两点： 是否有机器退出和加入：所有机器约定在父目录GroupMembers下创建临时目录节点，然后监听父目录节点的子节点变化消息。 一旦有机器挂掉，该机器与zookeeper的连接断开，所创建的临时目录节点被删除，所有其它机器都收到通知:某个兄弟目录被删除， 于是所有人都知道：它上船了。
选举master：所有机器收到通知：新兄弟目录加入，highcount又有了， 所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为master就好。
zookeeper分布式锁：锁服务分为两种： 一个是保持独占：将zookeeper上的要给znode看作是一把锁，通过createznode的方式来实现。 所有客户端都去创建 /distribute_lock节点，最终创建成功的那个客户端就拥有了这把锁。 用完删除掉自己创建的 distribute_lock节点就释放出锁。
一个是控制时序：distribute已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除，依次方便。
zookeeper队列管理：两种类型的队列： 1 同步队列，一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达（在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目）。
2 队列按照FIFO方式进行入队和出队操作（和分布式锁服务中的控制时序场景基本原理一致，入列又编号，出列按编号）。
分布式与数据复制： zookeeper作为一个集群提供一致的数据服务，自然，它要在所有机器间作数据复制。数据复制的好处：
1 容错：一个节点出错，不至于让整个系统停止工作，别的节点可以接管它的工作。
2 提高系统的额扩展能力：把负载分分布到多个节点上，或者增加节点来提高系统的负载能力。
3 提高性能：让客户端本地访问就近的节点，提高用户访问速度。
从客户端读写访问的透明度来看，数据复制集群系统分两种:
1 写主（WriteMaster）：对数据的修改提交给指定的节点。读无此限制，可以读取任何一个节点。这种情况下客户端需要对读和写进行区别，俗称读写分离。
2 写任意（Write Any）：对数据的修改可提交给任意的节点，和读一样。这种情况下，客户端对集群节点的角色与变化透明。
zookeeper 特性： *** 1 最终一致性：client不论连接到哪个Server，展示给它都是同一个视图。
2 可靠性：具有简单，健壮，良好的性能，如果消息被一台服务器接受，那么它将被所有的服务器接受。
3 实时性：zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。
但由于网络延时等原因，zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
4 等待无关：慢的或者失效的client不得干预快速的client的请求，使每个client都能有效的等待。
5 原子性：更新只能成功或者失败，没有中间状态。
6 顺序性：包括 全局有序 和偏序两种：
全局有序 是指 如果在一台服务器上消息 A 在消息 B前发布，则在所有 Server上消息 A都将在消息B前发布； 偏序 是指 如果一个消息B在消息A后被同一个发送者发布，A必将排在B前面。
zookeeper工作原理：zookeeper的核心是原子广播，这个机制保证了Server之间的同步。实现这个机制的协议叫做Zab协议。
Zab协议有两种模式，分别是 恢复模式（选主）和广播模式（同步）。
当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步后，恢复模式就结束了。 状态同步保证了leader和Server具有相同的系统状态。 为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。
zookeeper选主流程 （basic paxos） 当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。 Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。
1.选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server；
2.选举线程首先向所有Server发起一次询问(包括自己)；
3.选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存储到当前询问对象列表中， 最后获取对方提议的leader相关信息(id,zxid)，并将这些信息存储到当次选举的投票记录表中；
4.收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server；
5.线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 1的Server票数，设置当前推荐的leader为获胜的Server ，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来。 通过流程分析我们可以得出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n 1，且存活的Server的数目不得少于n 1. 每个Server启动后都会重复以上流程。 在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息，zk会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。
Zookeeper选主流程（fast paxos） fast paxos流程是在选举过程中，某Server首先向所有Server提议自己要成为leader， 当其它Server收到提议以后，解决epoch和 zxid的冲突，并接受对方的提议， 然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。
|
|
|
