赞
踩
- [5、什么时候创建新日志文件](#5_131) + [四、快照日志](#_142) + - [1、文件存储](#1_146) - [2、快照日志可视化](#2_154) - [3、相关配置](#3_178) - * [(1)snapCount](#1snapCount_182) * [(2)日志清理](#2_188) - [4、什么时候触发数据快照](#4_197) - * [(1)事务日志写入数量达到阈值snapCount](#1snapCount_201) * [(2)新Leader同步数据](#2Leader_209) + [五、ZooKeeper启动数据初始化和同步](#ZooKeeper_215) + - [1、加载并解析快照日志文件](#1_219) - * [(1)加载最新快照文件](#1_223) * [(2)解析快照文件](#2_231) * [(3)获取最新ZXID(zxid\_for\_snap)](#3ZXIDzxid_for_snap_235) - [2、事务日志进行数据修正](#2_241) - * [(1)获取zxid\_for\_snap之后提交的事务](#1zxid_for_snap_245) * [(2)数据修正](#2_249) * [(3)获取最新ZXID校验epoch](#3ZXIDepoch_255) - [3、数据同步](#3_265) - * [(1)Learner 向 Leader 发送 ACKEPOCH](#1Learner__Leader__ACKEPOCH_269) * [(2)Leader 初始化 peerLastZxid、minCommittedLog、maxCommittedLog](#2Leader__peerLastZxidminCommittedLogmaxCommittedLog_273) * [(3.1)直接差异化同步(DIFF)](#31DIFF_283) * [(3.2)先回滚再差异化同步(TRUNC+DIFF)](#32TRUNCDIFF_301) * [(3.3)仅回滚同步(TRUNC)](#33TRUNC_320) * [(3.4)全量同步(SNAP)](#34SNAP_328) + [六、数据备份与恢复流程](#_341) + - [1、为什么需要快照日志](#1_343) - [2、数据备份策略](#2_349) - [3、数据恢复](#3_359) + [七、要点总结](#_373) + [八、参考资料](#_389)
ZooKeeper
存储数据的底层数据结构是LSM
(Log Structured Merge-tree
)。基于LSM
实现的存储引擎有两个显著特点:MVCC
(Multi-Version Concurrency Control
)和存储KV
,即所有的更新操作,都是先追加事务日志,然后把key-value
存储到内存数据库,注意不是replace
,而是保存对一个key-value
的多个版本。
ZooKeeper
的数据备份与恢复,就用到了其事务日志文件和快照日志文件。快照日志文件是什么概念?为什么要有快照日志文件?
如何做数据备份?如何恢复数据?解开这些疑惑,需要深入了解ZooKeeper
底层是如何保证数据一致性和集群启动时如何做初始化数据加载和同步。
ZooKeeper
专门设计了 Zab
(Zookeeper Atomic Broadcast
)协议作为其数据一致性协议。所有写操作和客户端会话管理都以事务方式由 Leader
统一协调,使用两阶段提交的方式,保证数据一致性。
客户端和 ZooKeeper
集群中的任一服务建立连接,即可发送请求,请求主要包括两类,只读请求和事务请求。
只读请求包括 getData
、getChildren
、exists
等,zk服务器接收到只读请求无需转发给 Leader
,可直接本机处理响应。
事务请求包括 create
、delete
、setData
以及客户端会话的创建和销毁(createSession
、closeSession
)。
Leader
收到事务请求可以直接协调处理,并发给Follower
做数据一致性同步;Follower
收到事务请求就需要先转发给 Leader
,由Leader
统一生成事务提议。
事务请求是原子性和幂等的。
第一阶段是投票阶段,主要是让集群中半数以上的服务持久化事务请求到事务日志文件。所有事务请求由 Leader
统一生成事务提议广播给 Follower
,具体流程如下:
Leader
首先将事务请求持久化到事务日志文件中。Leader
生成事务提议,将其广播给所有 Follower
。Follower
收到事务提议,也将事务持久化到事务日志文件,并给 Leader
回应一个 ACK
消息,表示已做完事务持久化工作。第二阶段,Leader
收到半数以上的ACK
后,认为半数以上的服务都完成了事务日志持久化操作,可以继续将事务请求同步到内存数据库中,此为事务提交阶段。具体流程如下:
Leader
收到一半以上的 ACK
信息后,进入事务commit
阶段,Leader
先将事务请求同步到内存数据库。Leader
自己收到的事务请求,此时就可以响应客户端了。Follower
广播 COMMIT 消息。Follower
收到 COMMIT 后,将事务请求同步到内存数据库。Follower
收到的事务请求又转发给Leader,此时Follower
就可以响应客户端了。如下图分别为 Leader
接收到事务请求和 Follower
接收事务请求的处理过程:
需要注意,假设集群有3个服务节点,Leader
先将事务写入日志文件,相当于已经有一个服务节点完成了第一阶段(就是 Leader
自己),然后广播事务提议给 Follower
,只要有一个 Follower
响应了ACK
,Leader
就可以进入第二阶段 COMMIT
,此时Leader
将事务同步到内存数据库,就可以响应客户端了。
其实在集群中可能还会存在一种运行模式,即Observer
,和 Follower
一样统称为Learner
,也可以参与到数据同步的两阶段过程中,但是没有任何投票权利,Observer
无需回应ACK
给Leader
,Observer
不计入集群过半机制。
从两阶段流程可以看出,ZooKeeper
保证的是最终一致性,即 Leader
向客户端返回写入成功后,可能有部分 Follower
还没有写入最新的数据。
ZooKeeper
的最终一致性是严格的顺序一致性,所有事务请求统一由Leader
发起提议,严格按ZXID
顺序执行,当前事务请求没有处理完,再来新的事务请求就会阻塞。
ZXID
是由 Leader
生成的事务ID,是一个16进制的递增数字,共64位(二进制),由两部分组成:高32位代表当前Leader
任期编号,递增;低32位是事务计数器,递增,整体上是递增的。
ZooKeeper
适合读多写少的场景,读操作几乎是内存级别的,这得益于ZooKeeper
将数据保存在内存中。数据在内存中,就有一个问题,ZooKeeper
重启了数据还会在吗?
当然在了,ZooKeeper
将数据以事务日志形式持久化到文件中。每个更新请求,必须先将事务日志写到文件中,然后才把数据同步到内存数据库。
事务日志文件默认存储在dataDir
目录下,因为每次事务请求都是一次磁盘IO操作,事务日志的写入性能直接影响了ZooKeeper
对事务请求的吞吐,为了更高的吞吐和低延迟,建议单独为事务日志配置一个目录dataLogDir
,以免受其他操作影响。
dataLogDir
下会先生成一个子目录version2
,2表示ZooKeeper
日志格式的版本号,同一版本的日志可以互相迁移恢复数据。version2
下才是事务日志文件。
事务日志的文件有两个特点:
67108880KB
,即64MB
。文件大小都是64MB
,是因为日志文件的磁盘空间预分配。
事务日志不断追加写入文件的操作会触发底层磁盘IO为文件开辟新的磁盘块,即磁盘Seek,为了避免频繁的文件大小增长带来的磁盘Seek开销,ZooKeeper
在创建事务日志文件时就向操作系统预分配了一块比较大的磁盘块,保证了单一事务日志文件所占用的磁盘块是连续的,以此提升事务的写入性能。默认是64MB
,空闲部分用空字符(\0
)填充。
如果后续检测到文件空间不足4KB
,将扩容再次预分配64MB
,直到创建新的事务日志文件。
文件名后面的一串数字是事务ID:ZXID
,并且是写入事务日志文件的第一条事务ZXID
。前面讲了,ZXID
高32位是当前Leader
任期编号,低32位是事务计数器,比如 log.1400000001
、log.1400000003
,都是Leader
任期编号为20时产生的事务日志文件。
事务日志文件中存放的是二进制格式的数据,不能用vim、cat等工具直接打开,需要用apache-zookeeper-3.7.0
提供的脚本bin/zkTxnLogToolkit.sh
打开:
bin/zkTxnLogToolkit.sh logs/zoo-1/version-2/log.1400000003
一行就是一个事务记录,每行从左到右依次是操作时间、客户端session
ID、CXID
(客户端操作序列号)、ZXID
、操作类型(做了什么),如果操作类型是 createSession
,后面的30000就是session
的超时时间。
跟事务日志有关的配置除了dataLogDir
外,还有 preAllocSize
。
zoo.cfg
中默认没有显式配置dataLogDir
,事务日志和快照日志共享dataDir
。但是强烈建议,单独为事务日志指定dataLogDir
。
事务日志记录对磁盘性能要求极高,为了保证数据一致性,ZooKeeper
在返回客户端请求响应前,必须将本次请求对应的事务日志写入到磁盘中。因此,事务日志写入性能直接决定了ZooKeeper
在处理事务请求时的吞吐。
针对同一块磁盘的其他并发读写操作(如ZooKeeper
运行时日志输出和操作系统自身的读写等),尤其是数据快照操作,会极大影响事务日志的写性能。因此尽量给事务日志的输出配置一个单独的磁盘或是挂载点,极大提高ZooKeeper
整体性能。
java 系统属性: ZooKeeper.preAllocSize
,从字面意思就可以看出,preAllocSize
是用来配置事务日志文件预先分配文件大小的参数。默认65536
,单位KB
,即64MB
。
在进行事务日志写入前,ZooKeeper
会判断是否正在关联一个可写的事务日志文件,如果有则继续追加到该文件中,如果没有就需要创建新的日志文件并关联上。
什么时候ZooKeeper
没有关联上一个可写的事务日志文件呢?有两种情况:
ZooKeeper
停止会导致之前关联的事务日志文件断开,重启后第一次事务日志写入,需要创建新的日志文件。需要注意ZooKeeper
服务不要频繁重启,否则会产生很多日志文件,并且有些文件还没有写满,非常浪费磁盘空间。
快照日志是将ZooKeeper
服务器上某个时刻的全量内存数据,写入到指定磁盘文件中。可以这样理解,快照日志文件是存量数据,事务日志文件是增量数据,二者加起来就是最大限度的全量数据。
和事务日志类似,快照日志存放在dataDir
子目录version2
中,文件名为snapshot.ZXID
,不需要像事务日志文件一样预分配空间。
需要强调快照文件名后缀 ZXID
是触发快照的瞬间,提交的最后一个事务ID。如果是事务ZXID5
触发快照,那么快照文件名就是snapshot.ZXID5
,快照之后的下一个事务的ID是ZXID6
,新的事务日志名就是log.ZXID6
。
在数据恢复阶段,ZooKeeper
可以根据快照文件名后缀ZXID
,确定增量事务日志的起点文件。
快照日志内容同样也是二进制格式的,需要用 apache-zookeeper-3.7.0
提供的脚本bin/zkSnapShotToolkit.sh
打开:
bin/zkSnapShotToolkit.sh data/zoo-1/version-2/snapshot.1300000000 |less
快照日志记录每个节点的元信息,每个节点从上到下依次为:
cZxid
,创建这个节点时的事务ID。ctime
,创建节点时间。mZxid,
最后修改节点的事务ID。mtime,
最后修改节点时间。pZxid,
,该节点最后更新子节点列表的事务ID。cversion
,该节点子节点列表更新版本号,即子节点列表修改次数(不是子节点的值修改)。dataVersion
,节点数据版本号。aclVersion
,节点访问控制列表版本号。ephemeralOwner
,如果为临时节点,则为节点拥有者的sessionID
,如果不是临时节点则为0。dataLength,
,节点数据长度。快照日志相关的配置,除了dataLog
,还有snapCount
、autopurge.snapRetainCount
和autopurge.purgeInterval
。
java 系统属性: ZooKeeper.snapCount
,默认100,000,表示每写100,000次事务日志,触发一次快照,并滚动事务日志,即切换新的事务日志文件。
但是,实际情况,快照是一个比较好性能的操作。为了防止集群中的所有机器同时触发快照操作,当事务日志中的事务数量达到运行时[ snapCount/2 + 1,snapCount ]
范围内生成的随机值时,该ZooKeeper
服务器就触发一次快照。
每一个快照日志文件都是zk集群某个时刻的全量数据快照,理论上只需要最新的一个快照日志文件及其后面的事务日志即可,所以定时清理一些不需要的日志文件以节省磁盘内存资源。
日志的清理跟autopurge.snapRetainCount
和autopurge.purgeInterval
有关。
autoburge.snapretaincount
表示保留多少个快照日志文件,如果启动日志清理功能,zk会保留autoburge.snapretaincount
个最近的快照日志文件和 dataDir
和 dataLogDir
中相应的事务日志文件,并删除其余的。autopurge.snapRetainCount
默认为3,最小也是3。autopurge.purgeInterval
,清理任务触发的小时数时间间隔。设置为正整数(1及以上) ,以启用自动清洗。默认为0不启动。触发快照即生成新的快照日志文件有两种情况,事务日志写入数量达到阈值snapCount
和新Leader
同步数据。
每进行一次事务日志记录之后,ZooKeeper
都会判断当前是否需要进行数据快照。前面也说过,理论上进行snapCount
次事务操作后就会触发一次数据快照,但是考虑到数据快照对zk集群的整体性能影响,需要尽量避免所有机器同时进行数据快照。
所以采用过半随机策略,某个ZooKeeper
服务器的事务次数在[ snapCount/2 + 1,snapCount ]
范围内生成的随机值时,触发数据快照。
满足快照条件后,ZooKeeper
先进行事务日志文件的切换,即创建新的事务日志文件,然后再异步进行数据快照操作,尽量不影响正常流程。
运行中的ZooKeeper
集群,如果发生Leader重新选举,新Leader所在机器会检查最近一次快照之后是否有事务日志产生,有就对最近的一次事务之前的全量数据做一次数据快照。
ZooKeeper
服务器启动期间,需要进行数据初始化工作,就是将磁盘中的日志文件加载到ZooKeeper
服务器内存中,主要包括两个过程:从快照日志文件中加载快照数据和根据事务日志进行数据修正。
每一个快照日志文件都保存了某个时刻ZooKeeper
服务器全量数据,所以可以加载解析快照日志,先生成一棵DataTree
。
在 ZooKeeper
服务器运行期间,磁盘上会产生一些快照文件。更新时间最晚的那个文件包含了最新的全量数据,那么是否只需要这个最新的快照文件就可以了呢?
在 ZooKeeper
的实现中,会获取最新的至多100个快照文件(如果磁盘上存在不到100个快照文件,那么就获取所有快照文件)。这至多100个快照文件并不是全部都要加载和解析,而是先逐个进行数据正确性校验,校验通过就解析这个文件了,正常解析成功,就不会再向后加载检查。
这样做的目的就是防止某些快照文件损坏,最大力度恢复数据。
每个快照文件都是内存数据序列化到磁盘的二进制文件,因此需要对其进行反序列化,生成 DataTree
对象。
最新的快照文件解析成功后,根据该文件名解析出一个最新的ZXID
(zxid_for_snap
),即发生快照最后一次提交事务的ZXID
,找到这个ZXID
有什么用呢?
可以根据这个ZXID
找到快照之后对应的增量事务日志文件,进行数据修正。
只通过快照日志无法完全恢复数据,还需要根据事务日志进行增量数据修正。
快照日志文件处理完后,可以得到一个zxid_for_snap
,扫描加载文件名后缀大于zxid_for_snap
的事务日志文件,获取在zxid_for_snap
之后提交的所有事务。
最近很多小伙伴找我要Linux学习资料,于是我翻箱倒柜,整理了一些优质资源,涵盖视频、电子书、PPT等共享给大家!
给大家整理的视频资料:
给大家整理的电子书资料:
如果本文对你有帮助,欢迎点赞、收藏、转发给朋友,让我有持续创作的动力!
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
给大家整理的视频资料:
[外链图片转存中…(img-55CPYfRt-1714166021823)]
给大家整理的电子书资料:
[外链图片转存中…(img-W63ICCe2-1714166021824)]
如果本文对你有帮助,欢迎点赞、收藏、转发给朋友,让我有持续创作的动力!
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。