Zookeeper是个in-memory的文件系统，类 ZKDatabase是zk的存储模块,类中主要有以下成员:
- DataTree dataTree
数据库，主要存储了节点信息，所有节点均放在DataTree#nodes中，节点信息发生变化时，会触发类内部的IWatchManager对象通知给客户端，这是我们常用的功能。
- ConcurrentHashMap<Long, Integer> sessionsWithTimeouts
临时节点在会话结束后需要清除，所以需要有这个会话列表。
- FileTxnSnapLog snapLog
类似于redis的AOF日志。每有一个请求过来直接附加到一个日志中
- Long minCommittedLog，maxCommittedLog
最小和最大的提案zxid，leader内存中缓存一部分写请求log，如果节点加入了一个集群，这两个值在leader记录的范围内，那么直接sync这部分差异内容就可以了，便于快速加入集群。
zookeeper的具体数据由snapshot文件存储,snapshot的文件按照顺序由以下几个部件组成
- 标志信息
Int 固定字符"ZKSN"
Int 版本号
Long 数据库id
- session信息
Int session的数量sessionCout
接下来是sessionCount 个session的超时信息，每个的内容如下
Long sessionId
Int sessionTime
-- acls权限信息
Int acl数量
接下来是aclCount 个acl，每个的内容如下
Long index
Int perms
String scheme
String id
- 数据节点信息
若干个node节点，每个节点信息如下:
String path (""为root节点,"/"的情况下说明读取完毕)
String data
Long acl的index
状态信息:
Long czxid,mzxid,ctime,mtime
Int version,cversion,aversion
Long ephemeralOwner,pzxid
注意，snap中不需要存储节点间的关系，因为根据他们的path路径可以很直接的找到他们的关系。其中，有种特别的节点类型，path是/zookeeper/quota/${realpath}/zookeeper_limits。
他们的data用来存储realpath的限制信息(子节点的data大小和数量)。
snap文件dump的时机
1.learner(follower和Observer)从leader处同步到数据的时候。(分两种情况，DIFF方式，即增量模式不需要， SNAP模式，即全量时要)
2.启动时，如果有log文件，合并完成以后重新生成snapshot文件.
数据库的维护
1.合并逻辑
由于有log文件的存在，log文件并没有及时merge到数据库文件中，因此存储实际数据的snapshot文件并不一定是最新的。在zk启动时有以下步骤:1.加载最新的一个snapshot文件；2.调用fastForwardFromEdits将log文件的更改merge到内存中,并生成commitlog广播给其他节点。 3.重新生成干净的snapshot文件。
为方便管理，log文件和snapshot文件均以当前文件的最新zxid作为后缀。
2.旧文件清除
类DatadirCleanupManager用来定时清除log文件和snapshot文件。每次定时任务执行以下逻辑:
- 保留snapshot文件(最少3个)，并取得保留的snapshot中最旧的zxid。
- 将后缀小于这个zxid的snapshot文件和log文件都删除。
如果日志但是未提交，这条写操作是否生效？
分为两种情况讨论
日志未被写到过半节点
因为只要选举完成，数据就是以新的leader为准，如果
1.如果数据没有广播到过半节点，那么数据在记录了日志的节点均没有参与选举的情况下集群达到了一个新的纪元的情况下可能丢失:
由以下几点保证只要有写了日志的节点参与可恢复:
1.只有上轮的eader有写权限，并且zxid是自增的
2.tcp传输的顺序性和zk写日志的顺序性
日志被写到过半节点
如果日志广播到了过半节点并被写入log，那么这条数据肯定不会丢失，选举需要过半节点参与，因此zxid最大的节点必然会包含这条日志。在restore的过程中，leader会将为提交的propasal再次广播。
