Zookeeper学习

Zookeeper概述

        Apache ZooKeeper是由集群（节点组）使用的一种服务，用于在自身之间协调，并通过稳健的同步技术维护共享数据。ZooKeeper本身是一个分布式应用程序，为写入分布式应用程序提供服务，可以用于实现分布式系统中常见的发布/订阅、负载均衡、命令服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。

Zookeeper服务

• 命名服务：按名称标识集群中的节点，相当于DNS
• 配置管理：加入节点的最近的和最新的系统配置信息。
• 集群管理：实时的在集群和节点状态中加入/离开节点.
• 选举算法：选举一个节点作为作为协调目的的leader。
• 锁定和同步服务：在修改数据的同时锁定数据。
• 高度可靠的数据注册表：即使一个或多个节点挂掉，也同样可以获得数据。

Zookeeper架构

• Client(客户端)：分布式应用集群中的一个节点，从服务器访问信息，根据特定的时间间隔，会和服务器发送消息，使服务器知道客户端是活跃的。当客户端连接时，服务器发送验证码，如果服务器没有响应，客户端就会自动将消息重定向到另一台服务器上。
• Server(服务器)：Zookeeper服务中的一个节点，为客户端提供所有的服务。向客户端发送确认码以告知客户端自己是存活的。
• Ensemble:Zookeeper服务器组。形成ensemble所需的最小节点数为3.
• Leader:服务器节点，任何连接的节点失败，则执行自动恢复，leader在服务启动时被选举。
• Follower:跟随leader指令的服务器节点。

Zookeeper节点称为znode，每个znode有一个名称标识，并用路径（/）序列分开。在根目录下有两个逻辑命名空间，config和workers。config命名空间用于集中式配置管理，workers用于命名。在config命名空间下每个znode最多可以存储1mb的数据。

Zookeeper特性

• 顺序一致性：从一个客户端发起的事务请求，会严格按照发起的顺序应用到zookeeper中。
• 原子性：所有事务请求的处理结果在每一台服务器上都是一致的，不存在一部分服务器应用到，而另一台没有应用到的问题。
• 单一视图：所有客户端看到的服务端数据模型都是一致的。
• 可靠性：一旦服务端应用到了一个事务，其所引起的改变是持久的，直到被另一个事务所更改。
• 实时性：一个事务被成功应用后，zookeeper可以保证客户端立即读取到这个事务应用后变更后的最新数据。

Zookeeper设计目标

• 1.简单的数据模型存储数据：zookeeper通过树形结构存储数据，它由一系列的znode数据节点组成，类似于文件系统，不过他将数据存在内存中，实现了高吞吐、减少访问延迟。
• 2.构建集群：构建zookeeper服务集群，只要zookeeper集群中有半数服务可用，那么整个集群就可以正常服务。
• 3.顺序访问：对于每一个事务请求，zookeeper都会为之分配一个唯一的全局递增id,这个id反映了所有事务请求的先后顺序。
• 4.高性能高可用：zookeeper将数据保存在内存中实现高性能，通过部署zookeeper集群实现高可用。Zookeeper中的所有更新和删除都是基于事务的，所以在处理读多写少的应用场景中有很高的性能表现。

Zookeeper集群角色

• Leader:为客户端提供读写服务，并维护集群状态，它是及群选举产生的。
• Follower:为客户端提供读写服务，并定期向leader提供自己的状态，当然它也参与写操作(服务过半写成功)策略和leader选举。
• Observer：为客户端提供读写服务，并且定期向leader提供自己的状态，不参与leader选举，因此observer可以在不影响写性能的前提下提高集群读的性能。

会话

• Zookeeper通过TCP长连接连接到服务集群，会话从第一次连接开始就已经建立，之后通过心跳监测机制来确保会话连接状态。通过这个连接客户端可以发送请求并接受响应，同时也可以接收到watch事件的通知。
• Seeion timeout 由于网络故障或客户端断开连接等引起的连接断开，只要在会话超时时间之内重新连接则之前创建的会话依然有效。

数据节点

• 持久节点：客户端断开连接后持久节点依然存在，默认情况下znode都是持久的。
• 临时节点：客户端活跃时，临时节点就是有效的。当客户端与Zookeeper集合断开连接时，临时节点会自动删除。因此临时节点不允许有子节点。
• 顺序节点：顺序节点可以是临时的或者持久的。

Watchs(监视)

• 监视是一种简单的机制，使客户端收到关于Zookeeper集合中更改的通知。客户端可以读取特定znode时设置Watchs.（此刻认为有点像发布订阅模式，客户端订阅某个节点，这个节点更改后Watchs会向客户端发送更改通知）。Znode更改是与znode相关的数据的修改或znode的子项中的更改。只触发一次watches。如果客户端想要再次通知，则必须通过另一个读取操作来完成。当连接会话过期时，客户端将与服务器断开连接，相关的watches也将被删除。

Zookeeper的组件

• Follower:Follower从客户端接收写入请求，并将它们转发给leader znode.
• Leader: leader负责处理写入请求的znode.
• 请求处理器（request processor）:只存在于leader节点。它管理来自follower节点的写入请求。
• 写入：写入过程由leader节点处理。Leader将写入请求转发给所有的znode,等待znode的恢复，如果有一半的znode回复，则写入完成。
• 读取：读取直接在相应的znode内部执行，不需要进行集群交互。
• 复制数据库：用于在zookeeper中存储数据。每个znode都有自己的数据库，每个znode在一致性的帮助下每次都有相同的数据。
• 原子广播：负责广播从leader节点到follower节点的变化。（开启广播后就可以同步相当于当前的操作在所有节点中都会生效。）

Zookeeper leader 选举

Zookeeper的leader选举，首先一个zookeeper集群中有很多个znode,所有节点创建相同的路径，比如 app/leader_select/guid ,zookeeper集合会给这些路径后追加10位序列号，假设有3台服务器：
服务器1 app/leader_select/guid/0000000001,
服务器2 app/leader_select/guid/0000000002，
服务器3 app/leader_select/guid/0000000003,
这时会挑选一个最小数字的节点作为leader节点，而其它节点都是follower。每个follower节点监视下一个最小数字的节点，就比如3会监视2，2监视1如果leader节点上的服务器挂掉了，下一个在线的follower节点会通过监视器获得关于leader移除的通知，下一个在线follower节点将检查是否具有最小的znode,如果没有它就担任leader,如果有，就选择其作为leader。

Zookeeper 配置文件 zoo.cfg参数

• server.A=B：C：D：其中 A 是一个数字，表示这个是第几号服务器；B 是这个服务器的 ip 地址；C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；D 表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于 B 都是一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号。
  创建数据存储目录，对应配置文件中dataDir,然后在该目录下创建myid文件 存储A 声明该服务器是哪一台.

Zookeeper的使用场景

Zookeeper工作的模式从设计模式上看类似于观察者模式，就是一些znode注册到zookeeper上，Zookeeper提供监控这些节点上的数据变化，当这些节点上的数据发生变化时，Zookeeper通知注册其上面的观察者数据发生变化让其做出相应的反应。zookeeper充当一个注册中心。