简介：本文主要描述了zookeeper的工作原理和两大组件：zkdatabase和watch机制，适合作为原理理解。

Zookeeper的工作原理

        Zookeeper（以下简称ZK）是一个分布式环境下的事务的协调者，为其他分布式环境下的软件系统提供协调服务。它的主要工作为当分布式环境下系统出现数据不一致，用它来做最终的协调，也就是它来告诉分布式系统，你这个数据应该是什么。通俗的来讲，拿疫情来举例，当某个地区发生疫情时，各种小道消息满天飞，各个公司都不知道明天能否正常上班，到底是居家办公还是可以到公司办公。那么ZK就是来告诉你，明天是能上班还是不能上班。

        ZK是一个集群，集群中的每个节点，有三个角色，leader、follower和observer ，对应的介绍为：

        leader：集群的领导者，负责数据写入、发送数据确认和接收、新加入节点的数据同步、为客户端提供数据读服务。有选举权和被选举权

        follower：集群的节点，负责为客户端提供数据读服务，负责转发客户端的写请求给leader，有选举权和被选举权。

        observer：集权的观察者，负责为客户端提供数据读服务，负责转发客户端的写请求给leader，没有选举权和被选举权，主要使用场景是当zk集群压力过大时，使用observer节点来分摊压力。

        ZK实现的原理是什么呢，最基本的原理，也就是为其他系统服务的内核，是半数以上通过原则。这个原则体现在三个方面：

        1、选举确认，集群需要一个leader来做数据的写入者，这个leader的确认，需要半数以上的确认，当有半数以上的节点确认你是leader的时候，你才是leader。

        2、数据同步，zk为了给外部系统提供服务，需保证zk各个节点之间的数据是一致的，那么数据同步的时候，有半数以上的节点确认写入，这个数据才能对外提供，否则这个数据就不能对外提供。

        3、选举进行，什么样的场景会触发选举执行，刚启动时，需要选举出一个leader节点；集群运行过程中，当leader节点出现故障时。当然这只是表象，实际上是当集群中有任意一个节点加入（包括observer节点），都会出发选举执行，但因为leader已经确定，且满足半数通过原则，所以并不会出现leader存在的情况下leader节点的切换。

        ZK内部有三个机制或服务端口，选举执行（默认3888端口）、数据同步（默认2888端口）、客户端服务（默认2181端口）

        选举执行，默认使用3888端口进行通信，使用BIO网络通信机制。在启动时根据配置文件中的配置，已经知道了集群中总共有多少个选举节点，所以就清楚了半数通过的半数是多少，这为接下来的其他判断都提供了依据。在选举机制中，当存活节点不到半数时，集群是不能对外提供服务的状态，也就是必须有超过半数的选举节点存活，集群才有可能对外服务。小于等于时无法提供服务。选举执行时，以三个参数来判断选举谁：选举轮次、zxid(最大事务ID)、Myid(节点编号)，先判断选举轮次是否一致，小的节点的选票被忽略。当选举轮次一致时，判断最大事务ID，即判断数据，取最大的；当前面两个都一致时，那就取Myid最大的那个。

        数据同步：默认使用2888端口进行通信，也是使用BIO网络通信机制。当leader确定后才执行该动作，各个follower节点（observer节点也一样，在数据同步和客户端服务时，这两种类型节点功能一致，以下默认只写follower）发送自己的zxid给leader，leader跟自己做对比，小于自己的增加，大于自己的需要减少；当接收到写入请求时，由leader节点串行执行，leader节点写入成功后，会广播写入操作给所有节点，当半数以上的follower节点写入成功并反馈消息给leader时，这个写入事务才被确认。此时有人就会说了，这样会有没有写入成功的情况吧，数据会不一致吧，是的，会有这样的情况，这可以在客户端请求时，发送sync，要求follower强制同步数据给你返回。

        客户端服务：默认使用2181端口对外服务，使用NIO网络通信机制。当leader确认，半数以上的follower确认数据同步完成后，集群对外提供服务，此时同步没完成的是不提供服务的。follower节点接受到写入请求会转发给leader节点。

ZKdatabase

        这是zk内部的数据存储，它在内存保存树形结构，在磁盘保存日志记录。操作时先写入日志，然后写入内存。基本可以理解为同时。

        它跟普通的文件系统不同在于，它的节点，既可以存数据，也可以有子目录。

        按照是否永久存储，类型分为永久节点和临时节点，永久节点需要显式创建和删除，临时节点跟会话绑定，会话失效后自动删除。

        按照是否带编号，分为有编号节点和无编号节点，有编号节点创建时自动根据父节点中记录的最大序号+1进行保存。

        它内部存储数据最大为1M，建议不大于1K。这么设置的理由是：

                1、每个节点保持数据一致，大文件在leader串行写入慢；

                2、数据同步使用原子广播，大文件传播效率低；

                3、follower节点也需要执行写入，服务器性能不一样，会导致写入效率（最终确认需半数以上节点），有效率问题，并且数据存储在内存，吃内存太多。

                4、设计为分布式数据协调服务，并不是为了存储大量数据设计。可采用其他文件系统。

        

Watch机制

        Watch机制为观察者模式，即客户端可以注册监听，来监听zkdatabase中节点、子节点等变化情况，当出现变化时，zk会发送消息给客户端，进而完成相应的操作。

典型应用场景：

        集群管理：

        主节点管理：master抢注临时节点方式实现，抢注了临时节点并写入数据，其他节点无法创建，主节点在zkdatabase中维护任务等信息。当主节点异常后，备用节点抢注成功，接管任务。 hadoop、spark高可用就采用类似机制

        从节点管理：各个从节点注册到zk中，建立属于自己的临时节点。主节点监测目录，当从节点出现异常，则临时节点删除，主节点自动感知到从节点下线，执行相应管理策略。hbase的从节点管理采用此机制。

        分布式锁：注册临时节点实现