zookeeper 原理（一）

小咪咪 2022-10-06 06:54 167阅读 0赞

# 什么是zookeeper #

zookeeper是在分布式系统中解决分布式协调、负载均衡、发布订阅，master选举、分布式锁和分布式队列、集群管理、。 协调分布式系统下面的各个节点，为各个节点做整体的决策。

zookeeper分为服务器端和客户端，客户端可以连接到所有的服务端(除非服务端显示的制定不允许连接)。

## zookeeper数据结构 ##

ZooKeeper 提供的名称空间与标准文件系统的名称空间非常相似。名称是由斜线（/）分隔的一系列路径元素，。ZooKeeper中的每个节点都由一个路径标识。zookeeper中有个根节点是/，根节点下面是一个个子节点，子节点下面还可以挂子节点，形成了一个树形结构。可以将zookeeeper的数据结构类比文件系统层次结构

# 节点类型 #

*  临时节点，当前节点是临时的（具有一个生命周期，节点跟当前会话有关系）
 *  持久化节点，即使会话结束，节点依然存在服务器上
 *  有序节点，让节点带有有序的编号，有个递增的序号。
 *  父节点。先有父节点，再有子节点。临时节点下面不能存在子节点。
 *  同级节点下面名字必须是唯一的

# 节点存储内容 #

zookeeper节点里面包含了存储数据（Data），访问权限，子节点引用，节点状态信息

*  data: znode存储的业务数据信息
 *  acl: 记录客户端对znode节点的访问权限，如IP等
 *  child: 当前节点的子节点引用
 *  stat: 包含Znode节点的状态信息，比如事务id、版本号、时间戳等等.

## zookeeper系统架构 ##

ZooKeeper 分为服务器端（Server） 和客户端（Client），客户端可以连接到整个 ZooKeeper 服务的任意服务器上，  
客户端使用并维护一个 TCP 连接，通过这个连接发送请求、接受响应。组成 ZooKeeper 服务的服务器必须彼此了解，只要大多数服务器可用，ZooKeeper 服务就可用

# zookeeper有三种角色 #

## leader ##

*  leader节点负责写数据，更新系统状态，同时还负责投票的发起和决议

## follow ##

1.  处理客户端的请求。
2.  参与投票（对leader的提议进行投票）
3.  参与 过半提交投票，当客户端提交数据到zk服务端时候，当follow节点过半确认了，就可以返回客户端已经提交数据。follow过多导致性能下降，因为每个follow会参与投票

如果follower收到了客户端的事务请求，会请求转给leader处理

## observer ##

1.  解决follow过多，导致的性能下降。引入了observe节点
2.  observe节点**不参与投票吗，但是会参与数据同步**，只需要跟leader节点数据保持一致。
3.  observe也可以处理客户端的请求，在流量比较大的时候吗，可以加入一些observer节点

Zookeeper 建议**集群节点个数为奇数**，只要**超过一半的**机器能够正常提供服务，那么整个集群都是**可用**的状态。  
zookeeper启动的时候，会从实例中选举一个leader，leader负责处理数据更新操作，当大多数sever更新成功，就表示更新成功。

zookeeper的数据一致性是依靠的ZAB协议完成的。

# 写入数据过程 #

是一个2pc提交的过程，只允许唯一的一个 Leader 服务器来进行事务请求的处理，只有leader节点可以处理写请求。  
client的请求不关心是请求到是follow和leader。都有可能，但是如果follow收到的是一个事务请求，follower节点会将请求转发给leader节点。 leader节点接着会将这个事务请求，传递给集群中的其他follower节点（当前包含前面那个）。  
follower收到leader的事务操作请求后，会在本地记录一个事物日志，写入内存，但是还没有真的提交，接着返回leader节点一个ack，表明成功或者失败。leader收到各个follower的ack后，如果**超过半数**follower返回ack成功，那么会告诉客户端数据写入成功，同时leader会通知follower节点进行数据提交操作。 整个过程是2pc协议  
数据同步以后，因为数据是过半提交，所以follower并不是全部是一致，可能有些follower中间断开连接了，follower和leader之间有一个心跳请求，会向leader发起数据同步。整个过程中，leader是决策者

# 节点特性的实际应用场景 #

*  有序节点使用场景：  
    唯一全局id  
    分布式锁  
    分布式队列
 *  同级节点的唯一性可使用场景  
    如master选举，因为同级节点下相同的名字节点只能被创建一次，再次创建会失败。  
    分布式锁

# zookeeper分布式锁 #

*  1.利用同级节点写入实现  
    因为同级节点下面名字必须是唯一的  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2E3MTg1MTUwMjg_size_16_color_FFFFFF_t_70]
 *  2利用顺序节点实现

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2E3MTg1MTUwMjg_size_16_color_FFFFFF_t_70 1]

顺序节点实现分布式锁的原理是，  
判断当前节点的序号是不是最小的，如果是则获得锁，释放锁的时候，就是删除当前节点，然后通过监听唤醒下一个节点。

大致思想为：  
每个客户端在尝试获取锁时，会在 zookeeper 上生成一个唯一的**临时有序**节点。 判断是否获取锁的方式是，只需要判断是不是有序节点中序号最小的一个。 当释放锁的时候，只需将这个临时节点删除即可。而其余没有获取到锁的客户端只需要监听它的前一个节点即可.

由于是临时节点，客户端断开连接后，节点自动删除，解决了死锁问题。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2E3MTg1MTUwMjg_size_16_color_FFFFFF_t_70]: /images/20221005/fadd4ff18d164d7e89f8cb601a164360.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2E3MTg1MTUwMjg_size_16_color_FFFFFF_t_70 1]: /images/20221005/c9db7ce6bd844ffab30d05096c778159.png