ZoomKeeper学习笔记

Zookeeper简介

1分布式系统定义及⾯临的问题

        ZooKeeper最为主要的使⽤场景，是作为分布式系统的分布式协同服务。

        我们将分布式系统定义为：分布式系统是同时跨越多个物理主机，独⽴运⾏的多个软件所组成系统。类⽐⼀下，分布式系统就是⼀群⼈⼀起⼲活。⼈多⼒量⼤，每个服务器的算⼒是有限的，但是通过分布式系统，由n个服务器组成起来的集群，算⼒是可以⽆限扩张的。优点显⽽易⻅，⼈多⼲活快，并且互为备份。但是缺点也很明显。我们可以想象⼀下，以⼀个⼩研发团队开发软件为例，假设我们有⼀个5⼈的项⽬组，要开始⼀个系统的开发，项⽬组将⾯临如下问题：

        图中列举的就是项⽬组将要⾯临到的问题，这些问题在我们⽇常⼯作中也是天天发⽣，并没感觉有多么复杂，但是这是因为我们⼈类的⼤脑是个超级计算机，能够灵活应对这些问题，⽽且现实中信息的交换不依赖⽹络，不会因⽹络延迟或者中断，出现信息不对等，⽽且现实中对以上问题的处理其实并不严谨，从⽽也引发了很多问题。想⼀想，项⽬中是不是出现过沟通不畅造成任务分配有歧义？是否由于⼈员离职造成任务进⾏不下去，甚⾄要联系离职⼈员协助？是不是出现过任务分配不合理？类似这样的各种问题，肯定会发⽣于你的项⽬组中。在现实世界，我们可以⼈为去协调，即使出错了，⼈⼯去补错，加加班搞定就好。但在计算机的世界，这样做是⾏不通的，⼀切都要保证严谨，以上问题要做到尽可能不要发⽣。因此，分布式系统必须采⽤合理的⽅式解决掉以上的问题实际上要想解决这些问题并没有那么复杂，我们仅需要做⼀件事就可以万事⽆忧---让信息在项⽬组成员中同步。如果能做到信息同步，那么每个⼈在⼲什么，⼤家都是清楚的，⼲到什么程度也是清晰的，⽆论谁离职也不会产⽣问题。分配的⼯作，能够及时清晰的同步给每个组员，确保每个组员收到的任务分配没有冲突。分布式系统的协调⼯作就是通过某种⽅式，让每个节点的信息能够同步和共享。这依赖于服务进程之间的通信。通信⽅式有两种：

通过⽹络进⾏信息共享

        这就像现实中，开发leader在会上把任务传达下去，组员通过听leader命令或者看leader的邮件知道⾃⼰要⼲什么。当任务分配有变化时，leader会单独告诉组员，或者再次召开会议。信息通过⼈与⼈之间的直接沟通，完成传递。

通过共享存储

        这就好⽐开发leader按照约定的时间和路径，把任务分配表放到了svn上，组员每天去svn上拉取最新的任务分配表，然后⼲活。其中svn就是共享存储。更好⼀点的做法是，当svn⽂件版本更新时，触发邮件通知，每个组员再去拉取最新的任务分配表。这样做更好，因为每次更新，组员都能第⼀时间得到消息，从⽽让⾃⼰⼿中的任务分配表永远是最新的。此种⽅式依赖于中央存储。整个过程如下图所示

2 ZooKeeper如何解决分布式系统⾯临的问题

        ZooKeeper对分布式系统的协调，使⽤的是第⼆种⽅式，共享存储。其实共享存储，分布式应⽤也需要和存储进⾏⽹络通信。

        实际上，通过ZooKeeper实现分布式协同的原理，和项⽬组通过SVN同步⼯作任务的例⼦是⼀样的。ZooKeeper就像是svn，存储了任务的分配、完成情况等共享信息。每个分布式应⽤的节点就是组员，订阅这些共享信息。当主节点（组leader），对某个从节点的分⼯信息作出改变时，相关订阅的从节点得到zookeeper的通知，取得⾃⼰最新的任务分配。完成⼯作后，把完成情况存储到zookeeper。主节点订阅了该任务的完成情况信息，所以将得到zookeeper的完⼯的通知。参考下图，是不是和前⾯项⽬组通过svn分配⼯作的例⼦⼀模⼀样？仅仅是把svn和邮件系统合⼆为⼀，以ZooKeeper代替

        注：Slave节点要想获取ZooKeeper的更新通知，需事先在关⼼的数据节点上设置观察点。⼤多数分布式系统中出现的问题，都源于信息的共享出了问题。如果各个节点间信息不能及时共享和同步，那么就会在协作过程中产⽣各种问题。ZooKeeper解决协同问题的关键，就是在于保证分布式系统信息的⼀致性。

3 zookeeper的基本概念

        Zookeeper是⼀个开源的分布式协调服务，其设计⽬标是将那些复杂的且容易出错的分布式⼀致性服务封装起来，构成⼀个⾼效可靠的原语集，并以⼀些简单的接⼝提供给⽤户使⽤。zookeeper是⼀个典型的分布式数据⼀致性的解决⽅案，分布式应⽤程序可以基于它实现诸如数据订阅/发布、负载均衡、命名服务、集群管理、分布式锁和分布式队列等功能

集群角色

        通常在分布式系统中，构成⼀个集群的每⼀台机器都有⾃⼰的⻆⾊，最典型的集群就是Master/Slave模式（主备模式），此情况下把所有能够处理写操作的机器称为Master机器，把所有通过异步复制⽅式获取最新数据，并提供读服务的机器为Slave机器。⽽在Zookeeper中，这些概念被颠覆了。它没有沿⽤传递的Master/Slave概念，⽽是引⼊了Leader、Follower、Observer三种⻆⾊。Zookeeper集群中的所有机器通过Leader选举来选定⼀台被称为Leader的机器，Leader服务器为客户端提供读和写服务，除Leader外，其他机器包括Follower和Observer,Follower和Observer都能提供读服务，唯⼀的区别在于Observer不参与Leader选举过程，不参与写操作的过半写成功策略，因此Observer可以在不影响写性能的情况下提升集群的性能。

会话（session）

        Session指客户端会话，⼀个客户端连接是指客户端和服务端之间的⼀个TCP⻓连接，Zookeeper对外的服务端⼝默认为2181，客户端启动的时候，⾸先会与服务器建⽴⼀个TCP连接，从第⼀次连接建⽴开始，客户端会话的⽣命周期也开始了，通过这个连接，客户端能够⼼跳检测与服务器保持有效的会话，也能够向Zookeeper服务器发送请求并接受响应，同时还能够通过该连接接受来⾃服务器的Watch事件通知

数据节点（Znode）

        在谈到分布式的时候，我们通常说的“节点”是指组成集群的每⼀台机器。然⽽，在ZooKeeper中，“节点”分为两类，第⼀类同样是指构成集群的机器，我们称之为机器节点；第⼆类则是指数据模型中的数据单元，我们称之为数据节点——ZNode。ZooKeeper将所有数据存储在内存中，数据模型是⼀棵树（ZNode Tree），由斜杠（/）进⾏分割的路径，就是⼀个Znode，例如/app/path1。每个ZNode上都会保存⾃⼰的数据内容，同时还会保存⼀系列属性信息。

版本

        刚刚我们提到，Zookeeper的每个Znode上都会存储数据，对于每个ZNode，Zookeeper都会为其维护⼀个叫作Stat的数据结构，Stat记录了这个ZNode的三个数据版本，分别是version（当前ZNode的版本）、cversion（当前ZNode⼦节点的版本）、aversion（当前ZNode的ACL版本）。

Watcher（事件监听器)

        Wathcer（事件监听器），是Zookeeper中⼀个很重要的特性，Zookeeper允许⽤户在指定节点上注册⼀些Watcher，并且在⼀些特定事件触发的时候，Zookeeper服务端会将事件通知到感兴趣的客户端，该机制是Zookeeper实现分布式协调服务的重要特性

ACL

        Zookeeper采⽤ACL（Access Control Lists）策略来进⾏权限控制，其定义了如下五种权限：

               · CREATE：创建⼦节点的权限。

　　　　· READ：获取节点数据和⼦节点列表的权限。

　　　　· WRITE：更新节点数据的权限。

　　　　· DELETE：删除⼦节点的权限。

　　　　· ADMIN：设置节点ACL的权限。

        其中需要注意的是，CREATE和DELETE这两种权限都是针对⼦节点的权限控制