Zookeeper详解(八):Zookeeper数据存储

zookeeper日志有三类:快照(虽然不是日志但是它是数据)、事务日志(记录每次操作)、zookeeper自己系统日志。第三个不属于数据类所以这里不做说明。


快照数据

Zookeeper在运行时会在内存中维护一个完整的数据,就像内存数据库一样。ZKDatabase就是Zookeeper的内存数据库,负载管理Zookeeper的会话、存储和事务日志。它会定期dump一份数据快照到硬盘上,在Zookeeper启动时根据这个快照数据和事务日志来加载一份完整的数据到内存。这一点跟Redis很像,其实很多时候思路都是一样。

通过在配置文件中设置dataDir来指定快照保存位置。将内存数据库写入快照文件其实是一个序列化的过程。快照文件保存只是每个节点的元数据而非数据本身

那么每次快照间隔多久呢?

其实可以通过snapCount来进行配置,这个值得含义是每次快照之间的事务数量。也就是说执行多少次事务操作后进行一次快照。


  1. 每完成一次事务操作Zookeeper都会检查是否达到snapCount设置也就是来判断是否需要进行快照操作,因为快照本身对机器性能有影响,要避免集群中所有节点都进行快照

  2. 如果要进行快照操作,首先就需要对事务日志进行截断然后切换,所以事务日志写满不是以64M为标准而是以事务条数为标准的。

  3. 创建异步线程来执行快照操作(这一点又和Redis的bgsave一样)

  4. 从ZKDatabase中获取全量数据和会话,因为要保存内存所有数据节点信息和会话信息

  5. 生成快照名称,会根据已提交的最大ZXID来生成快照名称

  6. 数据序列化,首先会序列化文件头信息(魔数、版本、dbid信息),然后对会话信息和DataTree(Zookeeper内存数据的核心一个树形数据结构,代表内存完整数据)分别序列化,同时生成一个校验和,然后一起写入数据文件中。


事务日志

在配置文件中通过dataLogDir来配置事务日志路径,如果不配置默认保存在dataDir指定的路径下面。

Snip20180630_34.png

这些文件都是65M,其实是64M。而且都是以log.开头后面是一个十六进制数字作为后缀。这个后缀是一个ZXID它是写入该日志的第一个事务的事务ID,这样可以达到快速定位某一事务的效果。


日志写入过程:

  1. 当需要写入事务日志的时候Zookeeper会判断它是否和一个可写入的事务日志相关联,如果关联就写入,如果没有则用该事务的事务ID来创建一个事务日志,同时将这个事务日志对应的文件流放入到一个集合中(streamsToFlush),这个集合中记录的是当前需要强刷数据到磁盘的文件流(因为操作系统通常有延迟写入机制,对于Linux系统强刷等于调用fsync)。

  2. 事务日志文件采用预先分配空间策略,这样为了保证单一事务日志文件所占用的磁盘块是连续的,这也是为了提高性能。当Zookeeper发现当前正在写入的事务日志文件空间不足4KB时,就会启动预先分配空间策略进行扩容。第一次使用事务日志或者事务日志达到切割条数(snapCount参数触发快照)会启动预先分配策略;其他时候只要发现当前使用的事务日志空余不足4KB就进行扩容,扩容时使用0进行填充。

  3. 确保日志文件空间够之后就需要对进行事务序列化操作,最终产生一个字节数组。主要对事务头(TxnHeader)和事务体(Record)进行序列化。

  4. 根据序列化后的字节数据计算一个校验和

  5. 将字节数组和校验写入到文件流中。

  6. 由于该事务日志的文件流在集合中,这时候就会从集合里面取出文件流强刷落盘。

初始化

Zookeeper启动期间要完成数据初始化也就是将完整的数据加载到内存。它会根据快照和事务日志来完成加载过程。快照保存的是数据的元数据(不包括节点数据)而事务日志记录的操作和数据,那么使用快照+事务日志的方式可以还原完整的数据。它会先解析快照文件用于恢复出一个DataTree,此时就可以解析出个最新的ZXID,然后再根据ZXID来通过事务日志进行数据填充。另外还需要获取大于ZXID之后的事务日志进行应用。当完成数据恢复以后就可以获得一个最新的ZXID,这ZXID就是上次最后一个提交的事务ID。


完成初始化之后并且如果在集群环境中,Leader和其他服务器还会有一个数据同步过程。

Leader服务器会提取三个值:peerLastZxid(其他角色服务器最后处理的ZXID)、minCommittedLog(Leader服务器当前最小的ZXID)、maxCommittedLog(Leader服务器当前最大的ZXID)。

  • 差异同步:如果其他角色服务器的peerLastZxid介于minCommittedLog、maxCommittedLog那么就使用差异化同步,这时候Leader就知道他和对端服务器差多少,然后把这个差异进行发送再提交就是Zookeeper的两阶段提交。

  • 先回滚在差异同步:另外一种情况是在上一种情况下发生了意外原来的Leader要发送但是此时该Leader挂了,那么其余的会进行Leader选举,新的Leader产生后原来的Leader恢复了,那么显然他俩的ZXID有可能不同,新的Leader的ZXID小,但是要保证Leader的权威所以其他ZXID比它大的都要回滚到和现有Leader一样的状态或者小于Leader的ZXID的状态,然后在进行差异同步。

  • 仅回滚:也就是Leader让其他服务器都回滚到和自己一样的最大ZXID上

  • 全量同步:peerLastZxid小于Leader上的minCommittedLog,其实就是Leader将全部内存数据给Learner。这种情况通常用于在现有集群中又增加了一台Zookeeper服务器。

相关文章
相关标签/搜索