注册中心zookeeper

Zookeeper 分布式服务框架是Apache Hadoop 的一个子项目，由Yahoo构建，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、配置维护、分布式同步、分布式锁和分布式队列 等功能。

ZooKeeper的目标是将这些不同服务的本质提炼成一个非常简单的接口，以实现集中的协调服务。服务本身是分布式的，非常可靠。一致性、组管理和存在协议将由服务实现，这样应用程序就不需要自己实现它们。这些应用程序的特定用途将由ZooKeeper的特定组件和应用程序特定约定的混合组成。ZooKeeper展示了如何使用这个简单的服务来构建更强大的抽象。

zookeeper相关

客户端连接

客户端连接zookeeper：客户端启动，会和服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期就开始了。目的是通过这个长连接，进行心跳检测保证客户端和服务器的连接会话。双向的进行的，可以向服务器发送请求和接收响应，也能够接收来自服务器的监听事件通知。

客户端连接示意

Session

session 的 SessionTimeout 值用来设置一个客户端会话的超时时间。当由于服务器  压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在   SessionTimeout 规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话  仍然有效。

客户端以心跳的方式保持和服务端的会话连接。如果会话超时，则判断客户端已宕机。

 

树形结构（层次命名空间）

zookeeper用于内存存储的一个树形结构的文件系统，在和dubbo结合的时候，会给root节点命名为“dubbo”，在这个树上都是zNode，这个每个节点都可以用来存储数据。

在根目录下，有两个逻辑命名空间config和workers。在config下每个znode最多存储1MB数据。这么做的目的是存储同步数据并描述znode的元数据。

ZooKeeper数据模型中的每个znode都维护着一个 stat 结构。一个stat仅提供一个znode的元数据。它由版本号，操作控制列表(ACL)，时间戳和数据长度组成。

 

数据节点分为持久节点（persistent）和临时节点（ephemeral）

持久节点：创建到树上，就会一直存在，除非主动进行操作；

临时节点：生命周期跟客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的节点就会被剔除。因此，只有临时节点不允许有子节点。如果临时节点被删除，则下一个合适的节点将填充其位置。临时节点在leader选举中起着重要作用。

例如一个提供者，因为某些原因超时或宕机，zk就会检测不到提供者，那这个提供者就会被zk剔除。

监听事件

使用事件监听器Watcher，在zk发挥注册中心作用上很重要的特性，zk允许用户在指定节点上注册一些Watcher，并且事件触发时（例如dubbo提供者增加服务），zk服务端就会将事件通知给订阅的客户端。这是发布/订阅机制重要组成部分。

问题：一个项目肯定能有很多服务，那么zk监听哪些具体的节点？

Client可以在某个ZNode上设置一个Watcher，来Watch该ZNode上的变化。如果该ZNode上有相应的变化，就会触发这个Watcher，把相应的事件通知给设置Watcher的Client。

需要注意的是，ZooKeeper中的Watcher是一次性的，即触发一次就会被取消，如果想继续Watch的话，需要客户端重新设置Watcher

 

先理解节点是什么？一个客户端对应一个节点，zk是监控所有订阅的节点发送通知，例如dubbo里的消费者。

zookeeper集群

三种角色：leader、follower、client

集群最少三个，zk集群启动，客户端可以向任意节点连接，一旦客户端被连接，节点将向特定客户端分配SessionID并向该客户端发送确认。如果客户端没有收到确认，它将尝试连接ZooKeeper集合中的另一个节点。 一旦连接到节点，客户端将以有规律的间隔向节点发送心跳，以确保连接不会丢失。

问题1：为什么集群最少三个？

很简单，如果集群不出故障，几个节点都没有关系，但是这是不可能的。如果1个节点，节点故障，代表整个集群宕机；如果有2个节点，有一个故障，根据多数判断宕机，一个节点并不是多数；如果有三个节点，有一个节点故障，剩下两个就是多数，就可以判定有节点宕机；如果有四个节点，其中两个故障，剩下两个也不能成为多数，所以三个是最少最合适的节点数。

问题2：集群节点和树形节点的关系？

 

集群选举

在集群leader如果宕机或失去了大部分的follower，其他follower是可以通过选举，成为新的leader的。

问题：集群选举对线上的影响？

以dubbo为例，消费者和提供者一旦建立长连接，zookeeper出现宕机，对他们是没有影响的。只不过对某些节点需要订阅zk时，接收不到响应，就会换另外一台机器。

选举算法

zk选举有两种算法实现：basic paxos、fast paxos

basic paxos：

1 .选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server；
2 .选举线程首先向所有Server发起一次询问(包括自己)；
3 .选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，
并存储到当前询问对象列表中，最后获取对方提议的leader相关信息(id,zxid)，并将这些信息存储
到当次选举的投票记录表中；
4.  收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下
一次要投票的Server；
5.  线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得
n/2 + 1的Server票数， 设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置
自己的状态，否则，继续这个过程，直到leader被选举出来。
通过流程分析我们可以得出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且
存活的Server的数目不得少于n+1.

fast paxos：

在选举过程中，某Server首先向所有Server提议自己要成为leader，当其它Server收到提议以后，
解决epoch和 zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流
程，最后一定能选举出Leader。

除了和dubbo组合使用，还能在哪里使用？

Apache HBase使用ZooKeeper跟踪分布式数据的状态。

zookeeper底层了解不多，本篇会有很多认识上的问题，希望大家多多提意见和问题。