目录

1. ZooKeeper介绍

2. ZooKeeper选举机制（☆）

3. 节点类型

4. 监听器原理（☆）

5. 写数据流程

6. ZooKeeper的部署方式有哪几种？集群中的角色有哪些？集群最少需要几台机器？

7. CAP、BASE理论（☆）

1. ZooKeeper介绍

1. ZooKeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，ZooKeeper就将负责通知已经在ZooKeeper上注册的那些观察者做出相应的反应。

2. 特点

1）ZooKeeper：一个领导者（Leader），多个跟随者（Follower）组成的集群。

2）集群中只要有半数以上节点存活，ZooKeeper集群就能正常服务。

3）全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。

4）更新请求顺序进行，来自同一个Client的更新请求按其发送顺序依次执行。

5）数据更新原子性，依次数据更新要么成功，要么失败。

6）实时性，在一定时间范围内，Client能读到最新数据。

2. ZooKeeper选举机制（☆）

1）半数机制：集群中半数以上机器存活，集群可用。所以ZooKeeper适合安装奇数台服务器。

2）ZooKeeper虽然在配置文件中并没有指定Master和Slave。但是，ZooKeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。

3）以一个简单的例子来说明整个选举的过程。

假设有五台服务器组成的ZooKeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么，如图所示。

（1）服务器1启动，此时只有它一台服务器启动了，它发出去的报文没有任何响应，所以它的选举状态一直是LOOKING状态。

（2）服务器2启动，它与最开始启动的服务器1进行通信，互相交换自己的选举结果，由于两者都没有历史数据，所以id值较大的服务器2胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3)，所以服务器1、2还是继续保持LOOKING状态。

（3）服务器3启动，根据前面的理论分析，服务器3成为服务器1、2、3中的老大，而与上面不同的是，此时有三台服务器选举了它，所以它成为了这次选举的Leader。

（4）服务器4启动，根据前面的分析，理论上服务器4应该是服务器1、2、3、4中最大的，但是由于前面已经有半数以上的服务器选举了服务器3，所以它只能接收当小弟的命了。

（5）服务器5启动，同4一样当小弟。

3. 节点类型

持久：客户端和服务器端断开连接后，创建的节点不删除。

短暂：客户端和服务器端断开连接后，创建的节点自己删除。

说明：创建znode时设置顺序标识，znode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护。

注意：在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序。

（1）持久化目录节点：客户端与ZooKeeper断开连接后，节点仍存在。

（2）持久化顺序标号目录节点：客户端与ZooKeeper断开连接后，节点仍存在，只是ZooKeeper给该节点名称进行顺序编号。

（3）临时目录节点：客户端与ZooKeeper断开连接后，节点被删除。

（4）临时顺序编号目录节点：客户端与ZooKeeper断开连接后，节点被删除，只是ZooKeeper给该节点名称进行顺序编号。

4. 监听器原理（☆）

1. 监听原理详解：

1）首先要有一个main()线程

2）在main中创建ZooKeeper客户端，这时就会创建两个线程，一个负责网络连接通信（connect），一个负责监听（listener）。

3）通过connect线程将注册的监听事件发送给ZooKeeper。

4）在ZooKeeper的注册监听器列表中将注册的监听事件添加到列表中。

5）ZooKeeper监听到有数据或路径变化，就会将这个消息发送给listener线程。

6）listener线程内部调用了process()方法。

2. 常见的监听

1）监听节点的变化 get path[watch]

2) 监听子节点增减的变化 lspath [watch]

5. 写数据流程

1）Client向ZooKeeper的Server1上写数据，发送一个写请求。

2）如果Server1不是Leader，那么Server1会把接受的请求转发给Leader。因为每个ZooKeeper的Server里面有一个是Leader。这个Leader会将写请求广播给各个Server，比如Server1和Server2，各个Server写成功后就会通知Leader。

3）当Leader收到大多数Server数据写成功了，那么就说明数据写成功了。如果这里三个节点的话，只要有两个节点数据写成功了，那么就认为数据写成功了。写成功之后，Leader会告诉Server1数据写成功了。

4）Server1会进一步通知Client数据写成功了，这时就认为整个写操作成功。

6. ZooKeeper的部署方式有哪几种？集群中的角色有哪些？集群最少需要几台机器？

（1）部署方式单机模式、集群模式

（2）角色：Leader和Follower

（3）集群最少需要机器数：3

7. CAP、BASE理论（☆）

1.CAP理论指的是一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partitiontolerance）这三项中的两项。

（1）一致性：写操作之后的读操作，必须返回该值。

（2）可用性：意思是只要收到用户的请求，服务器就必须给出回应。

（3）分区容错：区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。

2.BASE指的是基本可用（BasicallyAvailable）、软状态（Soft State）和最终一致性（Eventually Consistent）下面展开讨论：

（1）基本可用

什么是基本可用呢？假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：

响应时间上的损失：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果。功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

（2）软状态

什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。

软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

（3）最终一致性

上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。

而在实际工程实践中，最终一致性分为5种：

①因果一致性（Causal consistency）

因果一致性指的是：如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。于此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制。

②读己之所写（Read your writes）

读己之所写指的是：节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。

③会话一致性（Session consistency）

会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。

④单调读一致性（Monotonic read consistency）

单调读一致性指的是：如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。

⑤单调写一致性（Monotonic write consistency）

单调写一致性指的是：一个系统要能够保证来自同一个节点的写操作被顺序的执行。