zookeeper

ZooKeeper服务：

官网：https://zookeeper.apache.org/

ZooKeeper介绍：

ZooKeeper是一个分布式服务框架，用来进行分布式环境的协调，它主要解决分布式应用中经常遇到的一些数据管理问题，如：命名服务、状态同步、配置中心、集群管理等

典型的分布式数据一致性解决方案，分布式应用程序可以基于ZooKeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能

最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心。服务生产者将自己提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据。如下图所示，在 Dubbo架构中 Zookeeper 就担任了注册中心这一角色

功能：

命名服务：

命名服务是分布式系统中比较常见的一类场景。命名服务是分布式系统最基本的公共服务之一。在分布式系统中，被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等——这些我们都可以统称它们为名字（Name），其中较为常见的就是一些分布式服务框架（如RPC、RMI）中的服务地址列表，通过使用命名服务，客户端应用能够根据指定名字来获取资源的实体、服务地址和提供者的信息等

状态同步：

每个节点除了存储数据内容和node节点状态信息之外，还存储了已经注册的APP的状态信息，当有些节点或APP不可用，就将当前状态同步给其他服务

配置中心：

现在我们大多数应用都是采用的是分布式开发的应用，搭建到不同的服务器上，我们的配置文件，同一个应用程序的配置文件一样，还有就是多个程序存在相同的配置，当我们配置文件中有个配置属性需要改变，我们需要改变每个程序的配置属性，这样会很麻烦的去修改配置，那么可用使用ZooKeeper来实现配置中心，ZooKeeper采用的是推拉相结合的方式：客户端向服务端注册自己需要关注的节点，一旦该节点的数据发生变更，那么服务端就会向相应的客户端发送Watcher事件通知，客户端接收到这个消息通知后，需要主动到服务端获取最新的数据

集群管理：

所谓集群管理，包括集群监控与集群控制两大块，前者侧重对集群运行时状态的收集，后者则是对集群进行操作与控制

使用场景：

希望知道当前集群中有多少机器在工作
对集群中每台机器的运行时状态进行数据收集
对集群中机器进行上下线操作

ZooKeeper特点

顺序一致性：从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到ZooKeeper中去
原子性：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用
单一系统映像：无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。
可靠性：一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖

zookeeper设计结构：

简单的数据模型

ZooKeeper允许分布式进程通过共享的层次结构命名空间进行相互协调，这与标准文件系统类似

名称空间由ZooKeeper中的数据寄存器组成：称为znode，这些类似于文件和目录。与为存储设计的典型文件系统不同，ZooKeeper数据保存在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟

可构建集群

为了保证高可用，最好是以集群形态来部署ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么zookeeper本身仍然是可用的

客户端在使用ZooKeeper时，需要知道集群机器列表，通过与集群中的某一台机器建立TCP连接来使用服务，客户端使用这个TCP链接来发送请求、获取结果、获取监听事件以及发送心跳包。如果这个连接异常断开了，客户端可以连接到另外的机器上

集群间通过Zab协议（Zookeeper Atomic Broadcast）来保持数据的一致性

顺序访问

对于来自客户端的每个更新请求，ZooKeeper都会分配一个全局唯一的递增编号，这个编号反应了所有事务操作的先后顺序，应用程序可以使用ZooKeeper这个特性来实现更高层次的同步原语。这个编号也叫做时间戳：zxid（Zookeeper Transaction Id）

高性能

ZooKeeper是高性能的。在“读”多于“写”的应用程序中尤其地高性能，因为“写”会导致所有的服务器间同步状态（“读”多于“写”是协调服务的典型场景）

当请求写入数据时，如果写请求到达slave节点，slave节点会把请求转交给leader节点写入，leader节点写入完成后，立即同步到其他slave节点。读取数据时，所有节点都能读取到同一个数据

zookeeper集群

集群角色：

最低3台主机，避免脑裂

Leader

Leader既可以为客户端提供写服务又能提供读服务
集群中leader主机通过投票，选举出来，一个集群只能有一个leader
事物请求的唯一调度、处理者，保证集群事物处理的顺序
集群内部各服务器的调度者

Follower

只能提供读服务
参与Leader的选举过程，参与写操作的“过半写成功”策略（leader数据同步其他三分之二节点，就返回成功，剩下未同步的继续同步）
处理客户端非事物请求，转发事物请求给leader服务器

Observer三种角色

只能提供读服务
不参与Leader的选举过程
不参与写操作的“过半写成功”策略
Observer机器可以在不影响写性能的情况下提升集群的读性能

client

请求发起者

集群选举：

当Leader服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB协议就会进人恢复模式并选举产生新的Leader服务器

选举过程

Leader election（选举阶段）：
- 1）由于是第一次选举leader，因此每个节点都会把自己当做leader角色进行选举，每个zookeeper的投票中都会包含自己的myid（server-id）和zxid，此时zookeeper 1的投票为myid为1，初始zxid有一个初始值，后期会随着数据更新而自动变化，zookeeper2的投票为myid为2，初始zxid为初始生成的值
- 2）每个节点接受并检查对方的投票信息，比如投票时间、是否状态为LOOKING状态的投票
- 3）对比投票，优先检查xvid，如果xvid不一样则xvid大的为leader，如果xvid相同则继续对比myid，myid 大的一方为leader

必要条件： Leader要具有最高的zxid；当集群的规模是n时，集群中大多数的机器（至少n/2+1）得到响应并 follow选出的Leader。心跳机制：Leader与Follower利用PING来感知对方的是否存活，当Leader无法响应PING时，将重新发起Leader选举

Discovery（发现阶段）：在这个阶段，followers跟准leader进行通信，同步followers最近接收的事务提议
Synchronization（同步阶段）：同步阶段主要是利用leader前一阶段获得的最新提议历史，同步集群中所有的副本。同步完成之后准leader才会成为真正的leader
Broadcast（广播阶段）：到了这个阶段，Zookeeper集群才能正式对外提供事务服务，并且leader可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步

leader挂后再次选举：

不再根据XVID、SID的大小进行判断，而是以数据的事物id做判断，谁的事物id时间最新（代表数据最完整，同步时间最接近）谁是leader

节点角色状态：

LOOKING：寻找Leader状态，处于该状态需要进入选举流程
LEADING：领导者状态，处于该状态的节点说明是角色已经是Leader
FOLLOWING：跟随者状态，表示Leader已经选举出来，当前节点角色是follower
OBSERVER：观察者状态，表明当前节点角色是 observer

选举 ID：

ZXID（zookeeper transaction id）：每个改变Zookeeper状态的操作都会形成一个对应的zxid
myid：服务器的唯一标识(SID)，通过配置myid文件指定，集群中唯一

ZAB 协议介绍

ZAB（ZooKeeper Atomic Broadcast 原子广播）协议
为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的原子广播协议。在ZooKeeper中，主要依赖ZAB协议来实现分布式数据一致性，基于该协议，ZooKeeper实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性

两种基本的模式：

崩溃恢复

当整个服务框架在启动过程中，或是当Leader服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB协议就会进人恢复模式并选举产生新的Leader服务器。当选举产生了新的Leader服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式

其中，所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和Leader服务器的数据状态保持一致

消息广播

当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进人消息广播模式了

当一台同样遵守ZAB协议的服务器启动后加人到集群中时，如果此时集群中已经存在一个Leader服务器在负责进行消息广播，那么新加人的服务器就会自觉地进人数据恢复模式：找到Leader所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。

正如上文介绍中所说的，ZooKeeper设计成只允许唯一的一个Leader服务器来进行事务请求的处理，Leader服务器在接收到客户端的事务请求后，会生成对应的事务提案并发起一轮广播协议；而如果集群中的其他机器接收到客户端的事务请求，那么这些非Leader服务器会首先将这个事务请求转发给Leader服务器

作为注册中心：

应用服务端启动（生产者）并注册到zookeeper服务
客户端启动（消费者），通过zookeeper上的watcher订阅频道
zookeeper通知客户端（消费者）事件更新
客户端通过zookeeper取到服务端信息后，直接与服务端通信（调用生产者）

zookeeper程序及脚本

端口：

2181 服务端口
2888 leader主机端口，用于集群数据同步
3888 follower主机端口，集群选举使用

程序脚本：

注意：所有脚本，只能在安装的bin目录下执行，软链接无效，执行时只能是完全路径

官方文档： https://zookeeper.net.cn/zookeeperTools.html
官方文档中，包含压测工具，以及相关脚本使用案例，推荐一看

zkServer.sh

启动zk服务

zkServer.sh [选项] 命令

start			后台启动服务
start-foreground	前台启动
stop
version
restart
status
print-cmd		打印当前使用的java命令

选项：
	--config 配置文件路径

zkCli.sh

zkCli.sh [选项] 命令

交互命令：
	help
	quit		#退出客户端
	create 路径 数据 	#创建
	set 路径 数据		#修改数据
	get 路径 
	stat 路径		#查看数据状态
	delete 路径		#删除数据

选项：
	-server 2.2.2.12:2181	#连接远程zk服务器

例：

create /node1 "2.2.2.12:9000"
get /node

stat /node1
#结果为
	cZxid= 	#leader生成按照数据写入顺序生成的zxid
	ctime=		#写入时间
	mZxid=		#最近更新zxid时间
	mtime=
	
delete /node1

zkCleanup.sh

清理日志和快照

zkCleanup.sh 日志数据快照 [选项]

选项：
	-n 保留数量

zkTxnLogToolkit.sh

恢复 CRC 损坏的事务日志条目，建议查看官方文档来

配置文件：

官方文档： https://zookeeper.apache.org/doc/r3.8.0/zookeeperAdmin.html

主配置文件zoo.cfg

############## 通用选项 ##############
tickTime=2000		#集群时，服务器与服务器之间的单次心跳检测时间间隔，默认2000ms
initLimit=10		#存活检测次数，检测通过10次为正常，10*2000ms，如果zk数据量很大，需要在增加此值
syncLimit=5		#leader数据写入时会广播给所有从节点，若指定时间内从节点同步失败，则会认为从节点失去连接，触发重新选举，也就是失败检测次数，如果该follower在设置的时间内(5*2000)不能与leader进行通信，那么此follower将被视为不可用
dataDir=/opt/zookeeper_data		#数据存放目录，快照存放
dataLogDir=			#事物日志存放位置，单独配置可避免日志记录和快照之间的竞争，对吞吐量和稳定的延迟优化很大
clientPort=2181			#客户端默认端口号
maxClientCnxns=512 		#单个客户端IP可以和zookeeper保持的连接数
autopurge.snapRetainCount=6		#ZooKeeper自动清除功能会将最新快照和相应的事务日志分别保留在dataDir和dataLogDir中，并删除其余部分（日志轮询文件个数），默认值为3。最小值为3
autopurge.purgeInterval=12		#自动清理日志和快照文件的功能，这个参数指定了清理频率，0为不开启，默认1h一次
metricsProvider.className=org.apache.zookeeper.metrics.prometheus.PrometheusMetricsProvider 		#启用普罗米修斯暴露器
metricsProvider.httpPort=7000
metricsProvider.exportJvmInfo=true 		#暴露jvm信息
metricsProvider.numWorkerThreads=1 		#指标暴露器工作线程，默认1
server.1=2.2.2.12:2888:3888 	#server.服务器编号=服务器IP:数据同步端口:选举端口
secureClientPort=端口 		#启用ssl端口
observerMasterPort=端口 		#观察者节点
globalOutstandingLimit=10 	#客户端提交请求的速度比zk处理请求的速度快，尤其是在客户端很多的情况下。为了防止zk因请求排队而耗尽内存，zk将限制客户端，以便系统中的未完成请求不超过 此配置，默认1000
preAllocSize=65536 		#创建数据文件（事物日志）时在磁盘上预分配的空间大小，为了减少频繁的磁盘分配操作，提高写入性能，配置过大可能浪费磁盘空间，默认64m
snapCount=100000 		#默认写入100000条事物时，触发1次快照写入，需注意，小了会频繁写磁盘，大了可能导致内存中数据丢失
commitLogCount=500 		#默认写入500条事物时，写入到事务日志中
snapSizeLimitInKb=4194304 	#默认内存中的数据大小达到或超过4g时，触发1次快照，负数为关闭
txnLogSizeLimitInKb=		#事物日志大小，超过此大小后，向新日志写入，建议最小为：2*preAllocSize，默认关闭
maxCnxns=0 		并发连接总数，默认0为无限制
maxClientCnxns=60 		#单个客户端并发连接数（套接字级别），默认60，0为无限制
maxSessionTimeout= 		#最大会话超时时间，默认值为：tickTime*20
fsync.warningthresholdms=1000 		#每当事务日志 （WAL） 中的 fsync 花费的时间超过此值时，都会向日志输出一条警告消息，默认1000ms
maxResponseCacheSize=400 		#缓存响应数据，存储最近读取记录的序列化形式的缓存的大小，节省常用 znode 的序列化成本，默认400，0或负数关闭
maxGetChildrenResponseCacheSize=400 		#子请求响应的缓存，默认400
autopurge.snapRetainCount=3 		#自动快照、事物日志清理，默认保留3份最新版
autopurge.purgeInterval=0 		#清理间隔，默认0为关闭，1为开启
syncEnabled=true 		#观察者像参与者一样记录事务并将快照写入磁盘。观察程序在重启时的恢复时间，默认true
extendedTypesEnabled=false 		#启用扩展功能，默认false关闭，启用后服务器id必须小于255
watcherCleanThreadsNum=2 		#观察器优化器，清理过期观察器时的线程数，默认2
watcherCleanThreshold=1000 		#服务器上的Watcher数量达到此配置时，进行批量清理过期观察器，没有内存或清理速度问题时，默认的足够了，默认1000个
watcherCleanIntervalInSeconds=10 	#清理间隔，默认10m，一般不用改
maxInProcessingDeadWatchers=数 		#观察器清理时能积压多少个，达到配置时，缓慢的向WatcherCleaner添加过期观察器，可避免oom，默认无限制，有压力时推荐为：watcherCleanThreshold * 1000
bitHashCacheSize=10 		#配置hash集合缓存大小，zk中位哈希是用于加速节点路径匹配的数据结构。将节点路径映射为一系列位（bit）的集合，以便快速进行路径匹配和查找，默认10
connectionMaxTokens=0 		#令牌桶中最大令牌数，令牌桶限速，用于客户端限流，默认0关闭
connectionTokenFillTime=1 	#令牌发放间隔，默认1ms
connectionTokenFillCount=1 	#发放令牌数，默认1/ms
connectionFreezeTime=-1		#调整丢弃概率时的间隔，ms单位，默认-1关闭
clientPortListenBacklog=50 	#客户端请求积压队列，zk响应不了时，加入此队列，队列满后来新请求会超时30s，默认50个
flushDelay=0  		#延迟刷写事物日志到磁盘，默认0关闭，如果允许的话，可改为10或20ms，提zk高吞吐量
maxBatchSize=1000 		#批处理请求时，最大数量，默认1000
maxConcurrentSnapSyncs=10 		#控制快照同步的并发数，默认允许10个快照同时同步
maxConcurrentDiffSyncs=100 		#当zk加入集群时，需要进行差异数据同步，此配置为允许并发进行的同步主机数量
snapshot.trust.empty=false 		#是否允许zk在空快照，或无快照的情况下启动，当zk版本是3.4.x，3.5.3 之前升级时，可以开启，启动后应改为false，并重启，默认false关闭
audit.enable=true 		#开启审计日志
largeRequestMaxBytes=字节 		#所有正在进行的大型请求的最大字节数。如果即将到来的大型请求导致超出限制，则连接将关闭。默认值为 100 * 1024 * 1024
netty.server.earlyDropSecureConnectionHandshakes=false  	#在重启时，tls相关连接出现异常时，丢弃连接，防止在重新启动后用许多并发TLS握手淹没服务器非常有用，但完全未启动期间不会响应：ruok命令，默认false
learner.closeSocketAsync=false 		#学习者将异步关闭仲裁套接字。tls连接中关闭套接字可能需要很长时间、阻塞关闭过程、可能延迟新的领导者选举以及使仲裁不可用。异步关闭套接字可以避免阻塞关闭过程，尽管套接字关闭时间很长，并且可以在套接字关闭时启动新的领导者选举。默认值为 false
leader.closeSocketAsync=false 		#领导者将异步关闭仲裁套接字。如果由于SyncLimitCheck失败而在ping（）中启动断开跟随程序的连接，则较长的套接字关闭时间将阻止向其他跟随程序发送 ping。如果不接收ping，其他关注者将不会向领导者发送会话信息，这会导致会话过期。将此标志设置为 true 可确保定期发送 ping。默认值为 false
learner.asyncSending=false 		#跟随者异步发送数据，需要根据场景考虑考虑异步可以提高性能，但有延迟，同步性能低，但无延迟。默认false关闭
forward_learner_requests_to_commit_processor_disabled=false 	#跟随者的请求不会排队到CommitProcessor（提交者处理器），有助于节省资源和 leader 上的 GC时间，但可能降低一些功能和一致性保证
############## 集群选项 ##############
FastLeaderElection=true 		#基于tcp快速leader选举
maxTimeToWaitForEpoch=秒		#选举新leader的最大等待时间，如果领导者收到来自其投票者之一的 LOOKING 通知，并且它没有收到来自 maxTimeToWaitForEpoch 内多数人的纪元数据包，则它将转到 LOOKING 并再次选举领导者。这可以进行调整以减少仲裁或服务器不可用时间，它可以设置为比 initLimit * tickTime 小得多。在跨数据中心环境中，可以将其设置为类似 2 秒的值。值大的话可以增加选举成功率，但增加选举时间
leaderServes=yes 		#leader将不接受客户端连接，仅用于协调，默认yes，允许客户端连接，3个zk集群以上时建议打开
cnxTimeout=5000 		#默认5s，zk与客户端连接超时时间
quorumCnxnTimeoutMs=-1  	#集群间总裁连接超时时间，默认-1，使用syncLimit * tickTime
standaloneEnabled=ture		#复制模式下启动单个服务器，默认true开启
reconfigEnabled=false 		#启用动态配置，默认false关闭，集群中配置不一致时，取决于leader在哪个节点，且节点是否开启此配置，开启则允许动态改，反之
4lw.commands.whitelist=命令 	#4字单词的命令，命令行白名单，允许使用的
	*为允许所有
	stat, ruok, conf, isro为仅允许这4个命令
	
tcpKeepAlive=false 		#启用tcp长连接，需在内核开启对应tcp长连接
clientTcpKeepAlive=false 	#为客户端套接字开启长连接，会通过空闲检查终止某些异常僵尸套接字，需在内核开启相关配置。此选项仅在使用默认值 NIOServerCnxnFactory 时可用
electionPortBindRetry=3 	#绑定leader选举端口时的失败重试次数，这种错误是暂时的可恢复的，k8s环境中应设为0（无限次），默认3
observer.reconnectDelayMs=0 	#观察者与leader失去连接时，等待多少ms后重新连接，默认0不等待
observer.election.DelayMs=200 	#观察者节点需要参与选举时，需要等一段时间后再开始选举过程，默认200ms
############## 性能 ##############
zookeeper.nio.numSelectorThreads=2 	#选择器线程用于处理网络连接和数据的读写操作。它们负责监听和接受客户端的连接请求，以及处理客户端和服务器之间的数据传输，建议为：cpus/2
zookeeper.nio.numWorkerThreads=2 	#nio工作线程数，默认cpus*2，0为主线程将直接处理请求
zookeeper.commitProcessor.numWorkerThreads=2 	#提交处理器工作线程数，默认cpus数，0为主线程将直接处理请求
znode.container.checkIntervalMs=60000 	#每次检查候选容器和 ttl 节点的时间间隔，默认6s
znode.container.maxPerMinute=10000 	#每分钟可以删除的最大容器和ttl节点数。这样可以防止在容器删除期间出现羊群效应，默认10000ms
############## 可观测性 ##############
zookeeper.messageTracker.Enabled=false 	#开启消息跟踪
zookeeper.messageTracker.BufferSize=10 	#控制存储在MessageTracker中的最大消息数，记录服务器（跟随者或观察者）与领导者之间的最后一组消息，当服务器与领导者断开连接时。这些消息集将被转储到zk的日志文件中，这将有助于重建断开连接时服务器的状态，并且对于调试目的很有用
admin.enableServer=true 		#默认开启管理端口
admin.portUnification=disabled 		#启用管理端口接收http、https流量
admin.forceHttps=disabled 		#管理端口强制https
admin.serverAddress=0.0.0.0 		#默认监听0.0.0.0
admin.serverPort=8080 			#默认端口

配置java.env

配置zookeeper的jvm，java选项可参考博主文章：
java参数
 容器构建java应用优化选项（这个详细点）

echo JAVA_OPTS='-Xmx2048m -Xms2048m ...其他java选项' > conf/java.env

zk服务启动问题（参考官方文档）

事物日志文件

由于zk事物日志文件损坏，出现IOException是，先确保集群中其他节点zk已经正常运行，并用zkCli.sh进入命令行界面：stat 路径，查看是否运行良好

确保都正常运行后，可清理损坏服务器的数据库，删除datadir配置目录下，version-2、datalogdir配置目录下，version-2，然后重启zk

快照文件：

可在配置文件，配置snapshot.trust.empty=true，允许空快照，或无快照文件启动，启动完成后应该关闭此项

数据备份

方法1：

数据目录：version-2
备份：

快照
事物日志
配置文件

方法2：

单独部署1台观察者主机，加入zk集群，仅用来备份数据，可实现热备

posted @ 2023-11-11 19:27 suyanhj 阅读(172) 评论(0) 收藏举报

刷新页面返回顶部

suyanhj