[Zookeeper系列002] Zookeeper高可用、高性能介绍

淡淡的烟草味﹌ 2024-02-18 23:27 16阅读 0赞

Zookeeper高可用、高性能且一致的开源协调服务，它提供了一项基本服务：统一命名服务、布式协调、存储数据、监听与通知等功能  
**分布式服务注册与订阅**  
在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑，比较典型的服务注册与订阅，消费端&生成端（负载均衡类似方案）

总结：系统之间存在某种订阅关系  
**分布式配置中心**  
适用：  
全局的配置信息  
服务式服务框架的服务地址列表

注意点：数据量很小，但是数据更新可能会比较快的场景

代表：百度的disconf  
github：https://github.com/knightliao/disconf  
**命名服务**  
在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，进程对象等等——这些我们都可以统称他们为名字（Name）。

总结：全局唯一的path、全局唯一性ID  
适用：  
其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用ZK提供的创建节点的API，能够很容易创建一个全局唯一的path，这个path就可以作为一个名称。

注意：所有向ZK上注册的地址都是临时节点，这样就能够保证服务提供者和消费者能够自动感应资源的变化  
**分布式通知协调**  
ZooKeeper中特有watcher注册不异步通知机制，能够很好的实现分布式环境下不同系统通知与协调，实现对数据变更的实时处理。使用方法通常是不同系统都对ZK上同一个znode中进行行注册，监听znode的变化（包括znode本身内容及子节点的），其中一个系统update了znode，那么另一个系统能够收到通知，并作出相应处理

总结：需要两双系统协调做一件事情  
适用：调度系统、推送系统、心跳检测等

需要两方系统一起做的事情，使用zookeeper来进行分布式通知和协调能够大大降低系统之间的耦合  
**分布式锁**  
分布式锁，这个主要得益于ZooKeeper为我们保证了数据的强一致性。锁服务可以分为两类，一个是保持独占，另一个是控制时序。  
所谓保持独占，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把zk上的一个znode看作是一把锁，通过create znode的方式来实现。所有客户端都去创建 /distribute\_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。  
控制时序，就是所有视图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了。做法和上面基本类似，只是这里 /distribute\_lock 已绊预先存在，客户端在它下面创建临时有序节点（这个可以通过节点的属性控制：CreateMode.EPHEMERAL\_SEQUENTIAL来指定）。Zk的父节点（/distribute\_lock）维持一份sequence,保证子节点创建的时序性，从而也形成了每个客户端的全局时序  
**分布式锁-排它锁**  
排它锁（Exclusive Locks，简称X锁），又称为写锁。  
如果事务T1对数据对象O1加上了排他锁，那么在整个加锁期间，只允许事务T1对O1进行读取和更新操作，其他任何事务都不能在对这个数据对象进行任何类型的操作（不能再对该对象加锁），直到T1释放了排他锁  
**分布式锁-共享锁**  
共享锁（Shared Locks，简称S锁），又称为读锁。  
如果事务T1对数据对象O1加上了共享锁，那么T1只能对O1进行读操作，其他事务也能同时对O1加共享锁（不能是排他锁），直到O1上的所有共享锁都释放后O1才能被加排他锁。  
**zookeeper客户端**  
ZkClient  
ZkClient是由Datameer的工程师开发的开源客户端，对Zookeeper的原生API进行了包装，实现了超时重连、Watcher反复注册等功能。  
Curator  
Curator是Netflix公司开源的一个Zookeeper客户端，与Zookeeper提供的原生客户端相比，Curator的抽象层次更高，简化了Zookeeper客户端的开发量。