ZooKeeper(总结)

        学习zookeeper我们得知道它是什么，能干什么，怎么干的，流程是怎么样的，有哪些注意事项！接下来我将一一解答

一、zookeeper定义

       官方定义:

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them, which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed.

翻译：

       ZooKeeper 是一种集中式服务，用于维护配置信息、命名、提供分布式同步和提供组服务。所有这些类型的服务都由分布式应用程序以某种形式使用。每次实现它们时，都需要做很多工作来修复不可避免的错误和竞争条件。由于难以实现这些类型的服务，应用程序最初通常会吝啬它们，这使得它们在发生更改时变得脆弱且难以管理。即使正确完成，这些服务的不同实现也会导致部署应用程序时的管理复杂性。

      看着是不是有点懵逼，这说的什么啊。那么我来给你解释一下，其实zookeeper是一个分布式的小型文件系统，什么是文件系统，通俗的解释就是我们一直用的此电脑、我的电脑就是一个文件系统的视图。只是我们平时用的比较大，一般在100个G，而zookeeper为啥说小呢，就是因为他的每一个文件（znode）只能存储kb级的文件。我们知道了它是什么，那么它能干什么呢，协调！对就是协调，他是一个分布式的协调服务，怎么来理解这个协调，举个现实的例子，十字路口的红路灯，警察叔叔就是起一个协调作用，那么zookeeper也是干这个活的，后面解释他是协调什么事的，这样你能理解他是什么，干什么的了嘛？

二、zookeeper的全局一致性

      全局一致性，什么要一致？怎么全局一致？如何保证他的一致？接下来让我们一下看看。首先要保证一致性，是要保证数据一致性，每一台服务上的数据都要相同，就比如下图，一共有三台主机master，slave1，slave2，中间存放的编号为1，2的文件，每一台都要有1，2文件，而且每一台的1、2文件要一样，这就是全局一致性。那么怎么保证全局一致性呢？

        要说保证全局一致性我们得了解什么是事务性操作和非事务性操作。我们都知道对于文件中的数据我们有增删改查操作，那么增删改就是事务性操作，查就是非事务性操作（读操作），了解了事务性操作和非事务性操作，我们来谈谈他是怎么保证数据一致性的，当slave1传来一条命令，我要改一下编号1文件的内容，slave2传来一条命令，我要删除编号1的文件，这个时候出现矛盾了怎么办，就得请大佬出场了master。slave1和slave2分别把两条命令上传给master，master将这两条命令按照事务请求的时间先后顺序进行排序，然后根据排序依次执行；比如先执行slave2的命令，那么编号1的文件删除了，那么执行slave1的命令时候就会提示错误信息，这样就保证了一致性。因此在zookeeper内部设置slave1和slave2只能执行非事务性操作，也就是只能进行读操作，将事务性操作内部转发给master。master根据时间将事务进行排序处理，当然master也具有处理非事务性操作的权限。

 三、zookeeper的主从架构

主从架构从上面的实例中我们应该很容易理解他的主从架构是一个怎么回事，就是一个主节点多个从节点，从节点只能处理非事务性操作，而主节点不仅能处理非事务性操作还能处理事务性操作。那么主节点应该是怎么来的呢，是谁相当就能当的嘛，实则不然，主节点需要通过选举来产生的，具体的产生过程是这样的：

在我们配置zookeeper的时候我们配置了myid的文件，选举的过程是需要借鉴的myid的内容来完成的。选举主节点的要求：当投票达到总服务器的一半时就确定主节点。

 如图这样主节点就选举出来了。

四、zookeeper的数据模型

zookeeper是一个目录树的结构

        他没有相对路径是由绝对路径，而且每一个节点都既是文件又是文件夹，就是它既可以保存数据，也可以在他下面继续创建文件，把这些节点统称为znode

zookeeper的数据模型分为四种，

1. 永久节点（PERSISTENCE）：  持久节点是 Zookeeper 的默认节点，Zookeeper 中最常用的一种节点类型，在使用 Zookeeper 场景中，几乎都要使用持久节点。持久节点被创建后会一直存在 ZooKeeper 服务器上，即使创建该节点的客户端与服务端的会话关闭了，该节点依然不会被删除，除非使用 delete 命令手动删除。
2. 永久节点序列化（PERSISTENCE_SEQUENTIAL）：  持久顺序节点是在持久节点的基础上，增加了顺序性。也就是说，持久顺序节点被创建时，ZooKeeper 服务器会自动使用一个单调递增的数字作为后缀，追加到我们创建节点的后边。会根据创建的时间进行编号，根据编号我们就可以判断它们的顺序。
3. 临时节点（EPHEMERAL）：  从这个名字上我们可以知道该节点类型最重要的特性就是临时性，临时节点与持久节点的特点相反，如果我们将某个节点创建为临时节点，那么该节点数据不会一直存储在 ZooKeeper 服务器上。临时节点被创建之后，如果与创建它的客户端断开连接或者是连接超时等原因，临时节点就会从我们的 Zookeeper 服务器上被销毁。同样的，我们也可以手动的删除我们的临时节点。
4. 临时节点序列化（EPHEMERAL_SEQUENTIAL）：  临时顺序节点就是在临时节点的基础上，增加了顺序性，与持久顺序节点一样，只不过我们创建的是临时节点。

 五、zookeeper的监听机制

1. 谁监听谁？ 客户端监听zk服务
2. 监听什么事？监听zk目录树znode的变化情况。如znode增加删除了、节点数据变化了、子节点变化
3. 监听实现步骤： ① zk客户端设置监听，然后zk服务执行监听； ② 事件发生，满足条件，触发监听 ③ zk服务把监听的事件回调通知给客户端

 

 特点：

•  先注册再触发：客户端必须先注册监听事件，服务端才可以开启监听动作；
• 一次性触发：事件发生，触发监听，这个效果是一次性的，后续再次发生同样的事件，不会再次触发；
• 事件封装：ZooKeeper使用WatchedEvent对象来封装服务端事件并传递，WatchedEvent包含了每一个事件的三个基本属性：通知状态（keeperState），事件类型（EventType）和节点路径（path）；
• event异步发送：watcher的通知事件从服务端发送到客户端是异步的。

 六、zookeeper的典型应用场景

1、数据发布/订阅

       数据发布/订阅系统即所谓的配置中心，也就是发布者将数据发布到ZooKeeper的一个节点上，提供订阅者进行数据订阅，从而实现动态更新数据的目的，实现配置信息的集中式管理和数据的动态更新。

2、集群选举服务

• 在分布式环境下，不管是主从架构集群，还是主备架构集群，要求在服务的时候有且有一个正常的对外提供服务，我们称之为master。
• 当master出现故障之后，需要重新选举出的新的master。保证服务的连续可用性。zookeeper可以提供这样的功能服务。

 

 3、分布式锁

• ZooKeeper通过数据节点表示一个锁，例如/itcast/lock节点就可以定义一个锁，所有客户端都会调用create()接口，试图在/itcast下创建lock子节点，但是ZooKeeper的强一致性会保证所有客户端最终只有一个客户创建成功。也就可以认为获得了锁，其它线程Watcher监听子节点变化（等待释放锁，竞争获取资源）。
• 此外也可以通过znode的序列化特性，给创建znode的客户端自动编号，从而实现所谓的顺序锁的功能。

 

 好了今天的分享就到这，如果文章有什么问题欢迎小伙伴们在评论区留言或者私信告诉我进行修改!