Zookeeper详解（八）：Zookeeper数据存储

xywuyiba6

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

　　

　　快照数据
　　Zookeeper在运行时会在内存中维护一个完整的数据，就像内存数据库一样。ZKDatabase就是Zookeeper的内存数据库，负载管理Zookeeper的会话、存储和事务日志。它会定期dump一份数据快照到硬盘上，在Zookeeper启动时根据这个快照数据和事务日志来加载一份完整的数据到内存。这一点跟Redis很像，其实很多时候思路都是一样。
　　通过在配置文件中设置dataDir来指定快照保存位置。将内存数据库写入快照文件其实是一个序列化的过程。快照文件保存只是每个节点的元数据而非数据本身。
　　那么每次快照间隔多久呢？
　　其实可以通过snapCount来进行配置，这个值得含义是每次快照之间的事务数量。也就是说执行多少次事务操作后进行一次快照。
　　

• 　　每完成一次事务操作Zookeeper都会检查是否达到snapCount设置也就是来判断是否需要进行快照操作，因为快照本身对机器性能有影响，要避免集群中所有节点都进行快照
  
• 　　如果要进行快照操作，首先就需要对事务日志进行截断然后切换，所以事务日志写满不是以64M为标准而是以事务条数为标准的。
  
• 　　创建异步线程来执行快照操作（这一点又和Redis的bgsave一样）
  
• 　　从ZKDatabase中获取全量数据和会话，因为要保存内存所有数据节点信息和会话信息
  
• 　　生成快照名称，会根据已提交的最大ZXID来生成快照名称
  
• 　　数据序列化，首先会序列化文件头信息（魔数、版本、dbid信息），然后对会话信息和DataTree（Zookeeper内存数据的核心一个树形数据结构，代表内存完整数据）分别序列化，同时生成一个校验和，然后一起写入数据文件中。
  
  

　　

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

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

　　日志写入过程：

• 　　当需要写入事务日志的时候Zookeeper会判断它是否和一个可写入的事务日志相关联，如果关联就写入，如果没有则用该事务的事务ID来创建一个事务日志，同时将这个事务日志对应的文件流放入到一个集合中（streamsToFlush），这个集合中记录的是当前需要强刷数据到磁盘的文件流（因为操作系统通常有延迟写入机制，对于Linux系统强刷等于调用fsync）。
  
• 　　事务日志文件采用预先分配空间策略，这样为了保证单一事务日志文件所占用的磁盘块是连续的，这也是为了提高性能。当Zookeeper发现当前正在写入的事务日志文件空间不足4KB时，就会启动预先分配空间策略进行扩容。第一次使用事务日志或者事务日志达到切割条数（snapCount参数触发快照）会启动预先分配策略；其他时候只要发现当前使用的事务日志空余不足4KB就进行扩容，扩容时使用0进行填充。
  
• 　　确保日志文件空间够之后就需要对进行事务序列化操作，最终产生一个字节数组。主要对事务头（TxnHeader）和事务体（Record）进行序列化。
  
• 　　根据序列化后的字节数据计算一个校验和
  
• 　　将字节数组和校验写入到文件流中。
  
• 　　由于该事务日志的文件流在集合中，这时候就会从集合里面取出文件流强刷落盘。
  

　　初始化
　　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服务器。