这篇文章主要介绍“ZooKeeper持久化原理是什么”，在日常操作中，相信很多人在ZooKeeper持久化原理是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”ZooKeeper持久化原理是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

ZK 的数据与存储中，有几个特别关注点：

1. 内存数据与磁盘数据间的关系：

• 恢复内存数据，恢复现场

• 数据同步：集群内，不同节点间的数据同步（另，内存中的提议缓存队列 proposals）

• 磁盘数据，为什么同时包含：快照、事务日志？出于数据粒度的考虑

• 因此粒度很细，恢复现场时，能够恢复到事务粒度上

• 因为生成快照的时间间隔太大，即，快照的粒度太粗了

• 如果只包含快照，那恢复现场的时候，会有数据丢失，

• 事务日志，针对每条提交的事务都会 flush 到磁盘，

• 内存数据，是真正提供服务的数据

• 磁盘数据，作用：

2. 快照生成的时机：基于阈值，引入随机因素

• countLog 为累计执行事务个数

• snapCount 为配置的阈值

• randRoll 为随机因素（取值：0～snapCount/2）

• 因为 dump snapshot 耗费大量的 磁盘 IO、CPU，

• 所有节点同时 dump 会严重影响集群的对外服务能力

• 解决的关键问题：避免所有节点同时 dump snapshot，

• countLog > snapCount/2 + randRoll，其中：

3. ZK 的 快照文件是 Fuzzy 快照，不是精确到某一时刻的快照，而是某一时间段内的快照

• RDB 文件是精确的快照，原因：进程之间内存空间隔离

• 系统内核使用「写时复制」（Copy-On-Write）技术，节省大量内存空间

• 线程之间共享内存空间，导致 Fuzzy 快照

• 这就要求 ZK 的所有事务操作是幂等的，否则产生数据不一致的问题

• 实际上 ZK 的所有操作都是幂等的

• ZK 使用「异步线程」生成快照：

• 类比：Redis 中使用「异步进程」生成快照 RDB（Redis Dump Binary）

https://blog.csdn.net/varyall/article/details/79564418

• 若在Zookeeper进行快照的过程中,接收了客户端的请求,此时会将该请求应用到DataTree吗?

• Zookeeper是调用zks.takeSnapshot()生成快照文件的,

• 这个方法及其底层的方法并没有对DataTree加锁,

• 因此生成快照文件并不是一个原子性的操作,

• 所以快照执行开始到快照执行结束期间发生的事务也会应用到DataTree中,

• 也会持久化到快照文件中,也即说明即使快照后缀名为n,此快照文件也有可能包含n+1,n+2这些事务的执行结果. 

• 若会,这会出现什么问题?如何解决? 

https://blog.csdn.net/jpf254/article/details/80769525

到此，关于“ZooKeeper持久化原理是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注天达云网站，小编会继续努力为大家带来更多实用的文章！