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处理完事务请求后再进行分发，以确保数据同步和一致性。非事务请求（查询请求）任何节点都可以处理。