代码拉取完成，页面将自动刷新
同步操作将从 Java精选/Ebooks 强制同步，此操作会覆盖自 Fork 仓库以来所做的任何修改，且无法恢复！！！
确定后同步将在后台操作，完成时将刷新页面，请耐心等待。
1）ZK有1MB 的传输限制。 实践中ZNode必须相对较小，而队列包含成千上万的消息，非常的大。
2）如果有很多节点，ZK启动时相当的慢。而使用queue会导致好多ZNode，需要显著增大initLimit和syncLimit。
3）ZNode很大的时候很难清理。Netflix不得不创建了一个专门的程序做这事。
4）当很大量的包含成千上万的子节点的ZNode时， ZK的性能变得不好。
5）ZK的数据库完全放在内存中。大量的Queue意味着会占用很多的内存空间。
尽管如此，Curator还是创建了各种Queue的实现。如果Queue的数据量不太多，数据量不太大的情况下，酌情考虑，还是可以使用。
version：当前ZNode版本
cversion：当前ZNode子节点版本
aversion：当前ZNode的ACL版本
当leader崩溃或者leader失去大多数的follower，这时zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。
Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。
1、Zookeeper选主流程(basic 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会在自己的文件系统上（树结构的文件系统）创建一个以路径为名称的节点，它可以指向提供的服务的地址、远程对象等。
简单来说使用Zookeeper做命名服务就是用路径作为名字，路径上的数据就是其名字指向的实体。
如果连接断开后，ZK不会马上移除临时数据，只有当SESSIONEXPIRED之后，才会把这个会话建立的临时数据移除。因此，用户需要谨慎设置Session_TimeOut。
client端会对某个znode建立一个watcher事件，当该znode发生变化时，这些client会收到zk的通知，然后client可以根据znode变化来做出业务上的改变等。
ZooKeeper由雅虎研究院开发，ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，后来托管到Apache，是Hadoop和Hbase的重要组件。
ZooKeeper是一个经典的分布式数据一致性解决方案，致力于为分布式应用提供一个高性能、高可用，且具有严格顺序访问控制能力的分布式协调服务。
ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
ZooKeeper包含一个简单的原语集，提供Java和C的接口。
ZooKeeper代码版本中，提供了分布式独享锁、选举、队列的接口，代码在$zookeeper_home\src\recipes。其中分布锁和队列有Java和C两个版本，选举只有Java版本。
于2010年11月正式成为Apache的顶级项目。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
分布式应用程序可以基于ZooKeeper实现数据发布与订阅、负载均衡、命名服务、分布式协调与通知、集群管理、Leader选举、分布式锁、分布式队列等功能。
集群最少要3台服务器，集群规则为2N+1台，N>0，即3台。
Master选举原理是有多个Master，其每次只有一个Master负责主要的工作，剩余的Master作为备份并负责监听工作的Master，一旦负责工作的Master挂掉，其他的Master就会收到监听的事件，从而去抢夺负责工作的权利，其他没有争夺到负责主要工作的Master转而去监听负责工作的新Master。
在分布式环境中，一般采用master-salve模式（主从模式），正常情况下主机提供服务，备机负责监听主机状态，当主机异常时自动切换到备机继续提供服务，也就是只需要集群中的某一台服务器进行执行，其他的服务器共享这个结果，从而减少服务器的重复计算，提高性能。其切换过程中选出下一个Master的过程就是master选举，因此需要进行leader选举。
服务端接收Watcher并存储
接收到客户端的请求，判断是否注册Watcher，如果需要注册Watcher就将数据节点路径和ServerCnxn存储到WatcherManager中的WatchTable和watch2Paths。
其中ServerCnxn表示一个客户端和服务端的连接，实现了Watcher的process接口，此时可以看成一个Watcher对象。
Watcher触发
假设服务端接收到setData()方法事务请求时触发NodeDataChanged事件。
封装WatchedEvent
将通知状态（SyncConnected）、事件类型（NodeDataChanged）以及节点路径封装成一个WatchedEvent对象。
查询Watcher
从WatchTable中根据节点路径查找Watcher对象，若果没找到说明没有客户端在该数据节点上注册过Watcher对象，反之找到的话就提取并从WatchTable和Watch2Paths中删除对应Watcher。从这里可以看出Watcher在服务端是触发一次就失效。然后调用process()方法来触发Watcher，process()方法主要通过ServerCnxn对应的TCP连接发送Watcher事件通知。
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
