ZooKeeper运维——数据备份与恢复(事务日志+快照日志,万字总结(4)

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化的资料的朋友,可以点击这里获取!

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

1、ZooKeeper如何处理请求

客户端和 ZooKeeper 集群中的任一服务建立连接,即可发送请求,请求主要包括两类,只读请求和事务请求。

(1)只读请求本机处理

只读请求包括 getDatagetChildrenexists 等,zk服务器接收到只读请求无需转发给 Leader,可直接本机处理响应。

(2)事务请求转发给Leader协调

事务请求包括 createdeletesetData 以及客户端会话的创建和销毁(createSessioncloseSession)。

Leader 收到事务请求可以直接协调处理,并发给Follower做数据一致性同步;Follower收到事务请求就需要先转发给 Leader,由Leader 统一生成事务提议。

事务请求是原子性和幂等的。

2、两阶段提交+过半数机制
(1)第一阶段提交事务请求

第一阶段是投票阶段,主要是让集群中半数以上的服务持久化事务请求到事务日志文件。所有事务请求由 Leader 统一生成事务提议广播给 Follower ,具体流程如下:

  • Leader 首先将事务请求持久化到事务日志文件中。
  • Leader生成事务提议,将其广播给所有 Follower
  • Follower 收到事务提议,也将事务持久化到事务日志文件,并给 Leader 回应一个 ACK 消息,表示已做完事务持久化工作。
(2)第二阶段执行事务提交

第二阶段,Leader 收到半数以上的ACK后,认为半数以上的服务都完成了事务日志持久化操作,可以继续将事务请求同步到内存数据库中,此为事务提交阶段。具体流程如下:

  • Leader 收到一半以上的 ACK信息后,进入事务commit阶段,Leader先将事务请求同步到内存数据库。
  • 如果是Leader自己收到的事务请求,此时就可以响应客户端了。
  • Leader 向所有Follower 广播 COMMIT 消息。
  • Follower收到 COMMIT 后,将事务请求同步到内存数据库。
  • 如果是Follower收到的事务请求又转发给Leader,此时Follower就可以响应客户端了。

如下图分别为 Leader 接收到事务请求和 Follower接收事务请求的处理过程:

Leader接收到事务请求

Follower接收到事务请求

需要注意,假设集群有3个服务节点,Leader 先将事务写入日志文件,相当于已经有一个服务节点完成了第一阶段(就是 Leader 自己),然后广播事务提议给 Follower,只要有一个 Follower响应了ACKLeader就可以进入第二阶段 COMMIT,此时Leader将事务同步到内存数据库,就可以响应客户端了。

其实在集群中可能还会存在一种运行模式,即Observer,和 Follower 一样统称为Learner,也可以参与到数据同步的两阶段过程中,但是没有任何投票权利,Observer无需回应ACKLeaderObserver不计入集群过半机制。

3、ZXID

从两阶段流程可以看出,ZooKeeper保证的是最终一致性,即 Leader 向客户端返回写入成功后,可能有部分 Follower 还没有写入最新的数据。

ZooKeeper的最终一致性是严格的顺序一致性,所有事务请求统一由Leader发起提议,严格按ZXID顺序执行,当前事务请求没有处理完,再来新的事务请求就会阻塞。

ZXID 是由 Leader 生成的事务ID,是一个16进制的递增数字,共64位(二进制),由两部分组成:高32位代表当前Leader任期编号,递增;低32位是事务计数器,递增,整体上是递增的。

ZXID

三、事务日志

ZooKeeper适合读多写少的场景,读操作几乎是内存级别的,这得益于ZooKeeper将数据保存在内存中。数据在内存中,就有一个问题,ZooKeeper重启了数据还会在吗?

当然在了,ZooKeeper将数据以事务日志形式持久化到文件中。每个更新请求,必须先将事务日志写到文件中,然后才把数据同步到内存数据库。

1、事务日志存放目录

事务日志文件默认存储在dataDir目录下,因为每次事务请求都是一次磁盘IO操作,事务日志的写入性能直接影响了ZooKeeper对事务请求的吞吐,为了更高的吞吐和低延迟,建议单独为事务日志配置一个目录dataLogDir,以免受其他操作影响。

dataLogDir下会先生成一个子目录version2,2表示ZooKeeper日志格式的版本号,同一版本的日志可以互相迁移恢复数据。version2下才是事务日志文件。

2、文件大小和后缀名

事务日志的文件有两个特点:

  • 文件大小出奇一致:都是67108880KB,即64MB
  • 文件名后缀是一串看似有些规律的数字,而且随着修改时间推移呈递增状态。

(1)磁盘空间预分配

文件大小都是64MB,是因为日志文件的磁盘空间预分配。

事务日志不断追加写入文件的操作会触发底层磁盘IO为文件开辟新的磁盘块,即磁盘Seek,为了避免频繁的文件大小增长带来的磁盘Seek开销,ZooKeeper在创建事务日志文件时就向操作系统预分配了一块比较大的磁盘块,保证了单一事务日志文件所占用的磁盘块是连续的,以此提升事务的写入性能。默认是64MB,空闲部分用空字符(\0)填充。

如果后续检测到文件空间不足4KB,将扩容再次预分配64MB,直到创建新的事务日志文件。

(2)ZXID作为后缀名

文件名后面的一串数字是事务ID:ZXID,并且是写入事务日志文件的第一条事务ZXID。前面讲了,ZXID高32位是当前Leader任期编号,低32位是事务计数器,比如 log.1400000001log.1400000003,都是Leader任期编号为20时产生的事务日志文件。

3、事务日志可视化

事务日志文件中存放的是二进制格式的数据,不能用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的超时时间。

4、相关配置项

跟事务日志有关的配置除了dataLogDir外,还有 preAllocSize

(1)dataLogDir

zoo.cfg中默认没有显式配置dataLogDir,事务日志和快照日志共享dataDir。但是强烈建议,单独为事务日志指定dataLogDir

事务日志记录对磁盘性能要求极高,为了保证数据一致性,ZooKeeper在返回客户端请求响应前,必须将本次请求对应的事务日志写入到磁盘中。因此,事务日志写入性能直接决定了ZooKeeper在处理事务请求时的吞吐。

针对同一块磁盘的其他并发读写操作(如ZooKeeper运行时日志输出和操作系统自身的读写等),尤其是数据快照操作,会极大影响事务日志的写性能。因此尽量给事务日志的输出配置一个单独的磁盘或是挂载点,极大提高ZooKeeper整体性能。

(2)preAllocSize

java 系统属性: ZooKeeper.preAllocSize,从字面意思就可以看出,preAllocSize是用来配置事务日志文件预先分配文件大小的参数。默认65536,单位KB,即64MB

5、什么时候创建新日志文件

在进行事务日志写入前,ZooKeeper会判断是否正在关联一个可写的事务日志文件,如果有则继续追加到该文件中,如果没有就需要创建新的日志文件并关联上。

什么时候ZooKeeper没有关联上一个可写的事务日志文件呢?有两种情况:

  • ZooKeeper停止会导致之前关联的事务日志文件断开,重启后第一次事务日志写入,需要创建新的日志文件。
  • 上一个事务日志文件写满了(达到阈值,触发了快照之后),需要创建新的日志文件。

需要注意ZooKeeper服务不要频繁重启,否则会产生很多日志文件,并且有些文件还没有写满,非常浪费磁盘空间。

四、快照日志

快照日志是将ZooKeeper服务器上某个时刻的全量内存数据,写入到指定磁盘文件中。可以这样理解,快照日志文件是存量数据,事务日志文件是增量数据,二者加起来就是最大限度的全量数据。

1、文件存储

和事务日志类似,快照日志存放在dataDir子目录version2中,文件名为snapshot.ZXID,不需要像事务日志文件一样预分配空间。

需要强调快照文件名后缀 ZXID是触发快照的瞬间,提交的最后一个事务ID。如果是事务ZXID5触发快照,那么快照文件名就是snapshot.ZXID5,快照之后的下一个事务的ID是ZXID6,新的事务日志名就是log.ZXID6

在数据恢复阶段,ZooKeeper可以根据快照文件名后缀ZXID,确定增量事务日志的起点文件。

2、快照日志可视化

快照日志内容同样也是二进制格式的,需要用 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,,节点数据长度。
3、相关配置

快照日志相关的配置,除了dataLog,还有snapCountautopurge.snapRetainCountautopurge.purgeInterval

(1)snapCount

java 系统属性: ZooKeeper.snapCount,默认100,000,表示每写100,000次事务日志,触发一次快照,并滚动事务日志,即切换新的事务日志文件。

但是,实际情况,快照是一个比较好性能的操作。为了防止集群中的所有机器同时触发快照操作,当事务日志中的事务数量达到运行时[ snapCount/2 + 1,snapCount ]范围内生成的随机值时,该ZooKeeper服务器就触发一次快照。

(2)日志清理

每一个快照日志文件都是zk集群某个时刻的全量数据快照,理论上只需要最新的一个快照日志文件及其后面的事务日志即可,所以定时清理一些不需要的日志文件以节省磁盘内存资源。

日志的清理跟autopurge.snapRetainCountautopurge.purgeInterval有关。

  • autoburge.snapretaincount表示保留多少个快照日志文件,如果启动日志清理功能,zk会保留autoburge.snapretaincount个最近的快照日志文件和 dataDirdataLogDir中相应的事务日志文件,并删除其余的。autopurge.snapRetainCount默认为3,最小也是3。
  • autopurge.purgeInterval,清理任务触发的小时数时间间隔。设置为正整数(1及以上) ,以启用自动清洗。默认为0不启动。
4、什么时候触发数据快照

触发快照即生成新的快照日志文件有两种情况,事务日志写入数量达到阈值snapCount和新Leader同步数据。

(1)事务日志写入数量达到阈值snapCount

每进行一次事务日志记录之后,ZooKeeper都会判断当前是否需要进行数据快照。前面也说过,理论上进行snapCount次事务操作后就会触发一次数据快照,但是考虑到数据快照对zk集群的整体性能影响,需要尽量避免所有机器同时进行数据快照。

所以采用过半随机策略,某个ZooKeeper服务器的事务次数在[ snapCount/2 + 1,snapCount ]范围内生成的随机值时,触发数据快照。

满足快照条件后,ZooKeeper先进行事务日志文件的切换,即创建新的事务日志文件,然后再异步进行数据快照操作,尽量不影响正常流程。

(2)新Leader同步数据

运行中的ZooKeeper集群,如果发生Leader重新选举,新Leader所在机器会检查最近一次快照之后是否有事务日志产生,有就对最近的一次事务之前的全量数据做一次数据快照。

冰冰冰冰

五、ZooKeeper启动数据初始化和同步

ZooKeeper 服务器启动期间,需要进行数据初始化工作,就是将磁盘中的日志文件加载到ZooKeeper服务器内存中,主要包括两个过程:从快照日志文件中加载快照数据和根据事务日志进行数据修正

1、加载并解析快照日志文件

每一个快照日志文件都保存了某个时刻ZooKeeper服务器全量数据,所以可以加载解析快照日志,先生成一棵DataTree

(1)加载最新快照文件

ZooKeeper服务器运行期间,磁盘上会产生一些快照文件。更新时间最晚的那个文件包含了最新的全量数据,那么是否只需要这个最新的快照文件就可以了呢?

ZooKeeper的实现中,会获取最新的至多100个快照文件(如果磁盘上存在不到100个快照文件,那么就获取所有快照文件)。这至多100个快照文件并不是全部都要加载和解析,而是先逐个进行数据正确性校验,校验通过就解析这个文件了,正常解析成功,就不会再向后加载检查。

这样做的目的就是防止某些快照文件损坏,最大力度恢复数据。

(2)解析快照文件

每个快照文件都是内存数据序列化到磁盘的二进制文件,因此需要对其进行反序列化,生成 DataTree对象。

(3)获取最新ZXID(zxid_for_snap)

最新的快照文件解析成功后,根据该文件名解析出一个最新的ZXIDzxid_for_snap),即发生快照最后一次提交事务的ZXID,找到这个ZXID有什么用呢?

可以根据这个ZXID找到快照之后对应的增量事务日志文件,进行数据修正。

2、事务日志进行数据修正

只通过快照日志无法完全恢复数据,还需要根据事务日志进行增量数据修正。

(1)获取zxid_for_snap之后提交的事务

快照日志文件处理完后,可以得到一个zxid_for_snap,扫描加载文件名后缀大于zxid_for_snap的事务日志文件,获取在zxid_for_snap之后提交的所有事务。

(2)数据修正

逐个对zxid_for_snap之后的事务进行内存同步,修复DataTree数据。如果该ZooKeeper服务器是Leader

在数据修正的过程中,每当有一个事务同步到内存数据库,就将这一事务记录转换成提议,保存到事务提议缓存队列中,为后续数据同步做准备。

(3)获取最新ZXID校验epoch

epoch字面意思是纪元、时代,在ZooKeeper中,epoch表示当前Leader任期。每次选举出一个新Leader后,epoch在原来基础上加1。

ZooKeeper集群在运行期间,服务间相互通信都会带上这个epoch,以确保彼此在同一个Leader任期内。

待所有的事务日志对数据修正后,获取一个最大的ZXID,即上次服务器正常运行时最后提交的事务ID。

从最大ZXID的高32位解析出该事务处理的Leader任期epoch,同时从磁盘的dataDir/version2目录下currentEpochacceptedEpoch文件中读取出最新的epoch值,进行校验。

3、数据同步

ZooKeeper服务器重启后,做完日志文件的加载和数据初始化,整个集群完成Leader选举或者本身就有Leader,此时,Learner服务器(Follower或者Observer)需要向Leader服务器进行注册,注册完成后,就进入数据同步阶段,即Leader服务器上的事务和Learner服务器的事务做对比,同步或者回滚。

(1)Learner 向 Leader 发送 ACKEPOCH

在注册Learner最后阶段,LearnerLeader 发送一个 ACKEPOCH 数据包,Leader从这个数据包中解析出该LearnercurrentEpochlastZxid

(2)Leader 初始化 peerLastZxid、minCommittedLog、maxCommittedLog

在开始数据同步之前,Leader 服务器首先从内存数据库中提取出事务请求对应的提议缓存队列,并完成以下三个ZXID的初始化:

  • peerLastZxid,将从Learner获取的lastZxid赋值给peerLastZxid
  • minCommittedLogLeader服务器提议缓存队列committedLog中的最小ZXID
  • maxCommittedLogLeader服务器提议缓存队列committedLog中的最大ZXID

通过 peerLastZxidminCommittedLogmaxCommittedLog 比较,有四种数据同步的方式:直接差异化同步(DIFF)、先回滚再差异化同步(TRUNC+DIFF)、仅回滚同步(TRUNC)、全量同步(SNAP

(3.1)直接差异化同步(DIFF)


![](https://img-blog.csdnimg.cn/img_convert/9a8cb5f8c0ec69e6499adead0da6e95b.png)


最全的Linux教程,Linux从入门到精通

======================

1.  **linux从入门到精通(第2版)**

2.  **Linux系统移植**

3.  **Linux驱动开发入门与实战**

4.  **LINUX 系统移植 第2版**

5.  **Linux开源网络全栈详解 从DPDK到OpenFlow**



![华为18级工程师呕心沥血撰写3000页Linux学习笔记教程](https://img-blog.csdnimg.cn/img_convert/59742364bb1338737fe2d315a9e2ec54.png)



第一份《Linux从入门到精通》466页

====================

内容简介

====

本书是获得了很多读者好评的Linux经典畅销书**《Linux从入门到精通》的第2版**。本书第1版出版后曾经多次印刷,并被51CTO读书频道评为“最受读者喜爱的原创IT技术图书奖”。本书第﹖版以最新的Ubuntu 12.04为版本,循序渐进地向读者介绍了Linux 的基础应用、系统管理、网络应用、娱乐和办公、程序开发、服务器配置、系统安全等。本书附带1张光盘,内容为本书配套多媒体教学视频。另外,本书还为读者提供了大量的Linux学习资料和Ubuntu安装镜像文件,供读者免费下载。



![华为18级工程师呕心沥血撰写3000页Linux学习笔记教程](https://img-blog.csdnimg.cn/img_convert/9d4aefb6a92edea27b825e59aa1f2c54.png)



**本书适合广大Linux初中级用户、开源软件爱好者和大专院校的学生阅读,同时也非常适合准备从事Linux平台开发的各类人员。**

> 需要《Linux入门到精通》、《linux系统移植》、《Linux驱动开发入门实战》、《Linux开源网络全栈》电子书籍及教程的工程师朋友们劳烦您转发+评论




**网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。**

**[需要这份系统化的资料的朋友,可以点击这里获取!](https://bbs.csdn.net/topics/618542503)**

**一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!**

  • 14
    点赞
  • 27
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值