zookeeper的设计原理及使用场景

zookeeper 作为一个分布式的服务框架,主要用来解决分布式集群中应用系统的一致性问题,解决分布式环境下多个进程或者多个中间件之间的同步控制,使有序访问某类资源。它能提供基于类似于文件系统的目录节点树方式的数据存储。zookeeper创建znode节点时,根据指定的类型mode不同,可以创建三种不同节点:临时节点、持久化节点和有序节点。

持久节点是一种非常有用的节点,持久节点的删除只能通过调用delete来进行删除,一般用来保存系统级的配置信息,一般项目中会有单独的系统来维护配置信息。

临时节点传达了应用某些方面的信息,当前会话session有效时znode节点信息存在,如果会话session过期或者主动关闭会话临时节点将会被删除。也就是一个临时的节点在以下两种情况下将被删除:当创建者的客户端的会话因为超时或者主动关闭而终止;当某个客户端主动删除该节点。

一个znode还可以设置为有序节点,一个有序的znode节点被分配唯一一个单调递增的整数。当创建有序节点时,一个序号会被追加到路径之后。例如,如果一个客户端创建了一个有序znode节点,其路径为/tasks/task-,那么zookeeper将会分配一个序号,如1,并将这个数字追加到路径之后,最后该节点的名称/tasks/task-1。

基于不同的znode节点特性,zookeeper可以解决多种场景问题,dubbo+zookeeper(服务注册和发现)、配置中心和分布式锁。

一、注册中心

可以借助zookeeper实现服务注册和发现功能,最常见的组合是dubbo+zookeeper。在一个分布式系统中,服务提供者向zookeeper注册中心注册服务,而服务消费者从注册中心订阅服务。zookeeper作为服务注册中心,对服务进行统一管理,提供地址服务。

二、配置中心

应用程序中配置信息包括application.properties、数据库配置、应用逻辑相关的常量配置、开关配置等,常用的配置方式是把这些配置信息放到各个应用程序中,这样当应用程序的配置信息发生变化时每次都需要重启应用程序。为了解决这类问题,可以把配置信息统一放至动态配置中心,由专门应用进行管理,zookeeper可以充当动态配置中心角色,专门存放项目中配置信息。应用启动时从配置中心读取配置信息并存放至应用程序缓存中,应用程序使用配置信息时直接从本地缓存获取,有效避免了多次远程配置信息获取。为使各应用程序中配置信息与配置中心保持一致,可以采用启动时全量同步、定时增量同步、设置监听、应急同步等多种手段。同时当配置中心配置发生变化时会push推送到各个应用。

三、分布式锁

利用zookeeper节点的唯一性特点可以实现分布式锁,znode节点在同一级别或路径下具有唯一性,如果节点已经存在,再次创建相同节点(set /lock 1)时就会报异常。假如都往zookeeper上注册lock节点(set /lock 1),根据节点唯一性,只有一个应用创建节点成功,如果该节点已经存在,说明其它应用已经成功注册一个节点(已经获取了锁)。所以分布式应用程序可以根据zookeeper的znode节点的唯一性特性实现分布式锁功能。

四、集群管理

常见组合是zookeeper+kafka,由zookeeper实现kafka集群管理。zookeeper实现高可用集群方式是中心式集群,一个中心节点leader,多个从节点follower。当leader节点出现异常时,可以从follower节点选举出一个新的leader节点。zookeeper集群为保障高可用的特性,所有事务请求(add/set/delete)统一由leader节点处理,如果事务请求到达follower节点,则follower节点会将事务请求转发给leader节点进行处理,leader处理完事务请求后再进行分发,以确保数据同步和一致性。非事务请求(查询请求)任何节点都可以处理。

猜你喜欢

转载自blog.csdn.net/wangpf2011/article/details/85550520