深夜读码-从zookeeper的数据持久化与快速加载说起

在当前的软件行业，持久化一直是一个热门的话题；
比如：如何保证数据不丢失？
如何快速的加载数据，恢复应用服务？
当单节点故障，如何保证数据不丢失？

这些都是亟待解决的问题。
先从zookeeper的数据说起，zookeeper的数据在内存中是以树形结构的datatree形式存在的，采用了两种方式进行数据的持久化，一种是定期的snapshot；一种是增量事务日志txnlog；

snapshot：记录了整个内存中的数据，即datatree的序列化；

txnlog：实时记录了所有访问zookeeper的事务请求，包括create、setdata、setacl、delete等等操作；

如何保证数据不丢失？

在zookeeper客户端请求zookeeper服务中，zookeeper的服务端首先是判断这个请求是否是事务请求，如果是事务请求，那么zookeeper服务端首先将这个请求记录在增量事务日志中，保证了其持久化，然后再进行更新内存数据datatree；在这个过程中，它也会去判断是否生成snapshot，如果要生成snapshot，那么就创建一个新的线程去干snapshot的事情；

如何快速的加载数据，恢复应用服务？

由于snapshot是定期生成的，所以它的数据可能不是最新的数据，如果我们只加载这个数据，难免会有漏数据，所以在zookeeper重启后，它会先去找到最新且合法的snapshot，这里有一个合法，其实就是校验其文件的完整性；加载完了之后，其实就是加载了zookeeper的一大部分数据，这时候会返回当前处理的最新的zxid，然后去增量事务日志中，找到大于等于zxid+1的事务记录，这样从这个记录开始，直至读取到文件结束，其实就完成了快速的加载数据。

如何保证单节点故障，不影响数据丢失呢？

zookeeper服务会在事务请求的时候，将事务请求转发给每一个参与决议的节点，即leader和follower，然后收到半数以上的返回后，才会更新自己的数据，紧接着才会返回给客户端响应；也就是在这个过程中一定有半数以上的节点完成了数据的持久化，这样解决了单节点故障，不丢失数据；

总结

其实zookeeper的这种持久化方案，在很多基础组件中都是如此的，比如很多数据库的持久化方案等等；所以知晓这种方案，也可以举一反三，希望这些知识对大家后续的工作中有所帮助！