zookeeper

zookeeper

使用场景

• Zookeeper做为一个分布式协调系统提供了一项基本服务：分布式锁服务，分布式锁是分布式协调技术实现的核心内容。像配置管理、任务分发、组服务、分布式消息队列、分布式通知/协调等，这些应用实际上都是基于这项基础服务由用户本身摸索出来的。
• 数据发布与订阅实现配置管理：发布与订阅即所谓的配置管理，顾名思义就是将数据发布到zk节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，地址列表等就很是适合使用。
• NameService：做为分布式命名服务，经过调用zk的create node api，可以很容易建立一个全局惟一的path，这个path就能够做为一个名称。
• 分布通知/协调：ZooKeeper 中特有watcher注册与异步通知机制，可以很好的实现分布式环境下不一样系统之间的通知与协调，实现对数据变动的实时处理。使用方法一般是不一样系统都对 ZK上同一个znode进行注册，监听znode的变化（包括znode自己内容及子节点的），其中一个系统update了znode，那么另外一个系统能 够收到通知，并做出相应处理。使用zookeeper来进行分布式通知和协调可以大大下降系统之间的耦合。
• 分布式锁：主要得益于ZooKeeper为咱们保证了数据的强一致性，即用户只要彻底相信每时每刻，zk集群中任意节点（一个zk server）上的相同znode的数据是必定是相同的。锁服务能够分为两类，一个是保持独占，另外一个是控制时序。控制时序中Zk的父节点（/distribute_lock）维持一份sequence,保证子节点建立的时序性，从而也造成了每一个客户端的全局时序。

数据结构

• ZooKeeper命名空间中的Znode，兼具文件和目录两种特色。既像文件同样维护着数据、元信息、ACL、时间戳等数据结构，又像目录同样能够做为路径标识的一部分。
• 每一个Znode由3部分组成:
  • stat状态信息：描述该Znode的版本, 权限等信息
  • data：与该Znode关联的数据(配置文件信息、状态信息、聚集位置)，数据大小至多1M
  • children：该Znode下的子节点
• ZooKeeper中的每一个节点存储的数据要被原子性的操做。也就是说读操做将获取与节点相关的全部数据，写操做也将替换掉节点的全部数据。
• 另外，每个节点都拥有本身的ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点能够执行的操做。

watch机制

• ZooKeeper能够为全部的读操做设置watch，包括：exists()、getChildren()及getData()。数据watch(data watches)：getData和exists负责设置数据watch,孩子watch(child watches)：getChildren负责设置孩子watch
• 当节点状态发生改变时(Znode的增、删、改)将会触发watch所对应的操做。当watch被触发时，ZooKeeper将会向客户端发送且仅发送一条通知，由于watch只能被触发一次，这样能够减小网络流量。

节点类型

• ZooKeeper中的节点有两种，分别为临时节点和永久节点(还可再分为有序无序)。
• 节点的类型在建立时即被肯定，而且不能改变。
• 临时节点：该节点的生命周期依赖于建立它们的会话。一旦会话(Session)结束，临时节点将被自动删除，固然能够也能够手动删除。虽然每一个临时的Znode都会绑定到一个客户端会话，但他们对全部的客户端仍是可见的。另外，ZooKeeper的临时节点不容许拥有子节点。（分布式队列）
• 永久节点：该节点的生命周期不依赖于会话，而且只有在客户端显示执行删除操做的时候，他们才能被删除。

zookeeper 架构

• 当集群节点数目逐渐增大为了支持更多的客户端，须要增长更多Server，然而Server增多，投票阶段延迟增大，影响性能。为了权衡伸缩性和高吞吐率，引入Observer：
• 每一个Server在工做过程当中有三种状态
  • LOOKING：当前Server不知道leader是谁，正在搜寻。
  • LEADING：当前Server即为选举出来的leader。

  • FOLLOWING：leader已经选举出来，当前Server与之同步。

    zookeeper工做原理

• 为了保证各个Server之间的同步， Zookeeper的核心是采用原子广播，实现这个原子广播的协议叫作Zab协议。
• 状态同步保证了leader和Server具备相同的系统状态。
• Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）

zab何时会进入恢复模式

• 当整个服务框架在启动过程当中
• 当Leader服务器出现网络中断崩溃退出与重启等异常状况
• 当有新的服务器加入到集群中且集群处于正常状态（广播模式），新服会与leader进行数据同步，而后进入消息广播模式

zab恢复模式干了什么

• 选举产生新的Leader服务器，同时集群中已有的过半的机器会与该Leader完成状态同步，这些工做完成后，ZAB协议就会退出崩溃恢复模式

zab恢复模式选主过程

• 当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式须要从新选举出一个新的leader，让全部的 Server都恢复到一个正确的状态。
• Zk的选举算法有两种：一种是基于basic paxos实现的，另一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。
• Basic paxos：当前Server发起选举的线程,向全部Server发起询问,选举线程收到全部回复,计算zxid最大Server,并推荐此为leader，若此提议得到n/2+1票经过,此为leader，不然重复上述流程，直到leader选出。

• Fast paxos:某Server首先向全部Server提议本身要成为leader，当其它Server收到提议之后，解决epoch和 zxid的冲突，并接受对方的提议，而后向对方发送接受提议完成的消息，重复这个流程，最后必定能选举出Leader。(即提议方解决其余全部epoch和 zxid的冲突,即为leader)。

  zk读写

• 同步流程

• （1）Leader等待server链接；
• （2）Follower链接leader，将最大的zxid发送给leader；
• （3）Leader根据follower的zxid肯定同步点，完成同步后通知follower 已经成为uptodate状态；
• （4）Follower收到uptodate消息后，又能够从新接受client的请求进行服务了

同步过程当中的事务

• 为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。全部的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

何时进入广播模式

• 集群状态稳定，有了leader且过半机器状态同步完成，退出崩溃恢复模式后进入消息广播模式

  广播模式干了什么

• 正常的消息同步，把平常产生数据从leader同步到learner的过程

zk四字操做命令

• nc为netcat命令的简写

echo stat | nc localhost 2181

conf: 输出相关服务配置的详细信息。
cons: 列出全部链接到服务器的客户端的彻底的链接 / 会话的详细信息。包括“接受 / 发送”的包数量、会话 id 、操做延迟、最后的操做执行等等信息。
dump: 列出未经处理的会话和临时节点。
envi: 输出关于服务环境的详细信息（区别于 conf 命令）。
reqs: 列出未经处理的请求
ruok: 测试服务是否处于正确状态。若是确实如此，那么服务返回“ imok ”，不然不作任何相应。
stat: 输出关于性能和链接的客户端的列表。
wchs: 列出服务器 watch 的详细信息。
wchc: 经过 session 列出服务器 watch 的详细信息，它的输出是一个与 watch 相关的会话的列表。
wchp: 经过路径列出服务器 watch 的详细信息。它输出一个与 session 相关的路径。
crst: 重置当前这台服务器全部链接/会话的统计信息
srst: 重置服务器的统计信息
srvr: 输出服务器的详细信息。zk版本、接收/发送包数量、链接数、模式（leader/follower）、节点总数。

还可使用telnet查看是否启动成功
telnet 10.1.101.162 2181链接后按回车，而后输入四字命令

zk异常

• 在Java API中的每个ZooKeeper操做都在其throws子句中声明了两种类型的异常，分别是InterruptedException和KeeperException。