Zookeeper系列（二十）Zookeeper原理解析之数据存储之ZKDatabase

ZKDatabase在内存中维护了zookeeper的sessions， datatree和commit logs集合。 当zookeeper server启动的时候会将txnlogs和snapshots从磁盘读取到内存中

6.1）loadDatabase: 跟数据库的启动类似zookeeper服务启动结合txnlogs和snapshot， snapshot是内存数据的某个点一份影像，takeSnapshot操作还是很耗时，为了性能根据某算法（在同步处理器SyncRequestProcessor中据一定算法得出一个count，记录大于count就要takeSnapshot，算法是: 100000/2 + random.nextInt(100000/2),这个十万是一个默认值可配置）计算出一个点来异步做一次takeSnapShot操作，这个跟数据库实现原理上很类似， 但是这样在非正常关机情况下，最新有效的那个snapshot并不是内存中最新的数据，所以需要利用txnLogs来把没有生成snapshot的操作在内存重新执行一边来恢复到非正常关闭服务那一刻内存情况。

            下面我们来看一下loadDatabase的流程：

            6.1.1) 构建一个PlayBackListener对象

            6.1.2) snapshot的反序列，倒叙排目录下的snapshot文件，遍历查找出最新的那个有效snapshot文件进行反序列化到内存（具体流程查看snapshot那部分介绍），snapshot的反序列后我们会知道snapshot最新的zxid叫做lastProcessedZxid, 这个lastProcessedZxid之前的事务操作，都成功执行并序列到snapshot中可恢复到内存，lastProcessedZxid之后的操作只有事务日志，不能直接通过snapshot恢复。

            6.1.2) lastProcessedZxid+1从事务日志文件txnLog读取事务操作

                 FileTxnLog txnLog = newFileTxnLog(dataDir);

        TxnIterator itr =txnLog.read(dt.lastProcessedZxid+1);

遍历TxnIterator，执行processTransaction方法，就是把事务操作在内存中在执行一边把丢失的操作补回来

       同时将事务操作通过PlayBackListener添加到commitedLog集合，commitedLog的事务操作在服务恢复的时候会同步到其他leaner server, 因为很有可能其他leaner server也没有及时的takesnapshot

                 返回最后的事务日志zxid给database，作为ZKDatabase的最新事物id

     6.1.3) 在zookeeperServer成功loadDatabase后，会及时主动的做一次takesnapshot操作来得到一份最新的内存影像