Zookeeper-Server端启动过程与处理类

ABKYH

　　Zookeeper服务端初始化过程,引导类:QuorumPeerMain.java.

 F1.Server端引导类执行过程

 

• snapshot文件是ZKDatabase内存数据的”快照”,当server接收到一定量的write操作或者达到时间间隔阀值,将会对内存数据进行一次本地文件序列化存储,每次存储将会生成一个snapshot文件,同时也会伴随一个log文件的生成.log文件为server执行的txn操作的预操作日志,每个write操作,都会首先被写入log日志.
  
• DatadirCleanupManager类,只负责定期清理那些相对”过时”的log/snapshot文件,只保留最新的N个文件,在确保ZKDatabase可以有效恢复数据的情况下,控制log文件的数量,避免不必要的文件无限制的增长.因为ZKDatabase中数据恢复时会涉及到遍历这两种文件的列表操作,文件个数多必然会带来问题.
  
• Txn-log和snap机制,参见稍后文档.
  
• ServerCnxnFacotry是管理ServerCnxn处理类的工厂,它负责对connection上数据处理的调度,以及server级别的一些处理,例如关闭指定session等.对于ZK而言,它支持两种ServerCnxnFactory实现:NIO模式和Netty,其中NIO模式为ZK默认的模式,当然也可以通过系统参数的方式指定为Netty,甚至可以是自定义类(系统参数:"zookeeper.serverCnxnFactory");ServerCnxnFactory职能: 1) 引导当前server的ZookeeperServer实例初始化(初始时为ReadOnlyZookeeper,当选举结束后,才会变更Server实例,参见下文) 2) 被动接受Client的IO链接,并维护所有链接的IO操作,这个是它的核心功能.ServerCnxnFacotry本身被设计成一个Thread,在完成初始化工作之后,就开始启动自身线程,在线程run方法中,采用NIO的方式Accept客户端连接,创建一个NIOServerCnxn实例,此实例和普通的NIO设计思路一样,它持有当前连接的Channel句柄和Buffer队列,最终将此NIOServerCnxn放入类Factory内部的一个set中,以便此后对链接信息进行查询和操作(比如关闭操作,IO中read和write操作等).
  

 

 F2.QuorumPeer类引导ZKDatabse加载过程

 

• zxid为ZK Cluster中所有"write"(或变更操作)的事务id号,我们可以简单的认为,任何变更操作都将有Leader分配一个zxid,用来标记此操作在整个集群数据库中是唯一的,zxid的顺序直接表示了操作被执行的顺序.
  
• epoch,这个词可能需要一段时间去接受,它的意思为"时代,纪元";ZK Cluster用epoch来表示和约束集群中所有server所处于的"纪元",一个新的Leader的产生,对于整个集群来说,就是一个"新纪元"; 那么对于Server而言,他们在选举之后,由Leader确认epoch的值,并交付给其他Server持久保存,并在此后的Leader和 Follower/Observer的通讯中都需要传递此值,并且它们必须处在同一"纪元"中;此外zxid的生成也可epoch有关.
  
• Snapshot文件内容需要一个magic格式的header,sessions列表,nodes列表,checkSum,”/”结束.在一个完整的snapshot文件中,顺序是严格的.checkSum是snapshot实际数据的校验和值,采用了Adler32方式,主要用来检测文件完整性以防止文件被外部程序修改.
  
• Snapshot文件列表,将按照zxid倒叙方式排列.snapshot文件格式snapshot.zxid.倒序方式来恢复数据,可以保证最近的序列化数据有限被”恢复”. Snapshot文件名的后缀是序列化时此文件所包含的最大的zxid(zxid戳).所以根据文件后缀,能够得知此文件生成的时机.
  
• 遍历snapshot文件列表时,只要发现最近的任何一个文件”校验”通过,均会终止遍历,因为最新的snapshot数据即可描述server的数据状态.
  
• TxnLog日志恢复的时候,会将500个(无法改变参数值)最近提交的提议(proposal)或者日志记录保存在zkdatabse中一个commentedLog的队列中,对于leader而言可以加速follower的同步操作.似乎对于follower,这个队列意义不大.
  
• 从文件恢复结束后,ZKDatabase/server,需要持有最大zxid的值,以及server失效前leader的epoch值.这些方便接下来的选举和数据同步.
  
• Txnlog文件会在snapshot时也会新建,文件格式为log.zxid,所以根据txnlog文件后缀,可以知道文件创建的时机.当然此文件名中的zxid是本文件中最小的zxid.
  

//数据恢复过程代码展示
File snap = null;
boolean foundValid = false;
for (int i = 0; i < snapList.size(); i++) {
snap = snapList.get(i);
InputStream snapIS = null;
CheckedInputStream crcIn = null;
try {
LOG.info("Reading snapshot " + snap);
snapIS = new BufferedInputStream(new FileInputStream(snap));
crcIn = new CheckedInputStream(snapIS, new Adler32());
InputArchive ia = BinaryInputArchive.getArchive(crcIn);
deserialize(dt,sessions, ia);
long checkSum = crcIn.getChecksum().getValue();
long val = ia.readLong("val");
if (val != checkSum) {
throw new IOException("CRC corruption in snapshot :  " + snap);
}
foundValid = true;
break;
} catch(IOException e) {
LOG.warn("problem reading snap file " + snap, e);
} finally {
if (snapIS != null)
snapIS.close();
if (crcIn != null)
crcIn.close();
}
}