zookeeper原理与应用

概述

分布式系统的应用程序注册中心

节点

1.四大类型

持久性节点

持久性顺序节点

临时性节点

临时性顺序节点

2.区别

• 持久性节点：只要你创建了这个节点，那不管你ZooKeeper的客户端是否断开连接，ZooKeeper的服务端都会记录这个节点；
• 临时性节点：与持久性节点相反，一旦你ZooKeeper客户端断开了连接，那ZooKeeper服务端就不再保存这个节点；
• 顺序性节点：在创建节点的时候，ZooKeeper会自动给节点编号比如0000001，0000002这种的

3.创建规则

无法创建同样的节点（名称相同，节点内的值无关） —— 待测试是否对所有类型节点都是这样

监听机制

客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）等，Zookeeper会通知客户端。

应用

分布式锁

概述

根据节点的创建规则，所以可以利用需要获取锁的对象创建zookeeper节点的操作成功与否，判断用户是否成功获取分布式锁。
由于监听机制的存在，等待锁的用户无需不断尝试获取锁，只需要在收到删除锁的通知后尝试获取锁即可。

特点

顺序性：服务获取锁的顺序：与zookeeper调度中心收到的服务获取锁请求的先后顺序一致。

1.如何避免死锁

1.1.死锁是什么

当创建了节点的服务在删除节点前挂了，导致节点没能删除，但其他用户一直在等通知，那么用死锁了

1.2.如何避免：使用临时节点

使用临时节点，临时节点会随着服务的断开而自动删除，即自动释放锁。不应该使用持久节点创建分布式锁，因为这种节点不会随创建节点的服务的断开而自动删除。
但是使用临时节点时，当所有服务都监听同一个节点时（尝试获取同一把锁），那么当节点删除时所有的服务都会收到“删除”消息，从而应发“惊群现象”，但我们应该避免这种现象的发生。

2.如何避免惊群效应

2.1.什么是惊群效应

当某一锁可用时，多个服务会惊醒，同时竞争资源

2.2.为什么要避免惊群效应

2.2.1.避免无效系统开销

对竞争锁的服务来说：避免发起无效请求
若100个服务竞争一个锁，最终只能有一个服务能成功获取锁，对于其他不能获取锁的服务，尝试获取锁的竞争将是一个无效的调用。

对zookeeper调度中心来说：保证服务性能（响应速度）
当调度中心瞬间涌入几百个服务的创建锁请求时，CPU开销增大，对调度中心的其他请求的响应速度可能就会下降。

2.2.2.保证每个服务都能获取锁

“惊群”的本质是每个服务公平竞争锁，但这种公平也是相对的。因为锁的获取可能受网络、服务性能的多方面影响，每个服务成功获取锁的概率也不一样，因此，可能出现总有某几个服务总是获取不到锁。

2.3.如何避免惊群效应：使用临时顺序性节点

使用临时顺序性节点，每一个服务器监听自己前面的一个节点。
当收到监听的节点被删除的消息，就会尝试去获取锁，这样每次只唤醒一个服务来竞争资源。

3.实现逻辑

假设100个服务器同时发来请求，这个时候会在/zkjjj节点下创建100个临时顺序性节点/zkjjj/000000001，/zkjjj/000000002，一直到/zkjjj/000000100，这个编号就等于是已经给他们设置了获取锁的先后顺序了。
当001节点处理完毕，删除节点后，002收到通知，去获取锁，开始执行，执行完毕，删除节点，通知003~以此类推。