Zookeeper系列一：Zookeeper基本应用介绍

一、基本应用介绍

1. 默认根目录下面有一个节点，zookeeper；

2. create /xxoo "" 在根目录下面创建节点;

3. get /xxoo/ooxx 获取节点的值， 每个节点的值只能放1M，并且是二进制安全的，所谓二进制安全的就是外界客户端给zk推送什么字节数组，zk只负责存储。

 cZxid：创建节点事务id，zk是顺序执行，所有的写操作给到zk中任何角色的时候，都会递交给leader， leader是单机的，所以维护一个递增序列很容易；

ctime： 创建节点时间；

mZxid： 修改节点的事务id；

mtime： 修改节点的时间；

pZxid:   代表当前节点下创建的最后节点的id号；

ephemeralOwner: 代表创建临时节点的session号。 create -e代表创建临时节点  create -t代表创建持久节点。临时节点伴随session的会话期。

4. zk会统一视图，如果客户端连接的其中一个server挂掉之后，在fail-over的时候 ，连接到另外一台server的时候，session不变。因为所有的server都会统一session。这就是动用zk的统一视图，进行数据同步。

5.  客户端断开，session在所有的server中删除掉，这个时候存在统一视图的过程，删除所有server中的session，会消耗一个事务id。

6.  create -s 可以创建不会重复的节点名称，zk会自动增加一个递增的序列号。防止并发创建相同节点的时候覆盖掉原有的节点。防重复命名，也就叫分布式id获取，如果删除掉以前的序列节点，后面新创建的还是会递增，因为统一视图会维护原有的序列号。

 

7. zk的功能：

1. 统一配置管理，通过每个节点的1M数据；

2. 分组管理：通过path结构，也就是所谓的分层命名空间；

3. 统一命名： sequential  create -s;

4. 分布式同步： 通过临时节点  create -e;

应用场景：

1. 分布式锁： 设置一个临时节点。连接挂掉，session消失，对应的ephemeral节点跟着消失。依托一个父节点且具备-s，代表父节点下可以有多把锁，可以实现带队列模式的锁模型；

2. HA选主；

3. 发布订阅等功能

 

8. zk底层是原语的，千万不要当数据库用，查可以，但是千万不要写大量数据，做持久化等；它就是一个分布式协调的很好的工具。

9.  zk是一个主从集群，所有的写操作都在leader身上，读操作可以在follower身上。如果leader挂掉，服务不可用，就会带来一个问题，不可靠。但是事实是zk集群及其高可用。zk集群运行有两种状态，分别是可用状态和进入无主模型后的不可用状态。下面图中是zk官网做的一个测试，七台机器组成的集群，第3和第5个事件是领导者挂了，测试结果是在领导者挂了之后，通过自己的选举算法，200ms即可以选举出新的leader，重新恢复之前的吞吐量。

10.  ZooKeeper非常快速且非常简单。但是，由于其目标是作为构建更复杂的服务（例如同步）的基础，因此它提供了一组保证。这些是：

• 顺序一致性，来自客户端的写操作将会按照顺序执行，因为所有的写请求最终都会到达单机的leader上面，它可以更好的维护序列号；
•        原子性-更新成功或失败。没有部分结果。也就是所谓的统一视图。
•        单系统镜像-无论客户端连接到哪个服务器，客户端都将看到相同的服务视图。也就是说，即使客户端故障转移到具有相同会话的其他服务器，客户端也永远不会看到系统的较旧视图。
•        可靠性—也就是持久性，应用更新后，此更新将一直持续到客户端覆盖更新为止。
•        及时性—-保证系统的客户视图在特定时间内是最新的。其实是最终一致性的概念，在一定时间范围内给出最新的数据。