AppBoxFuture的存储引擎依赖Raft一致性协议来保证各个分区副本的一致性,如果不处理Raft日志将不断增长,因此需要特定的机制(定期或每处理一定数量的日志)来回收那些无用的日志数据。通过学习Raft协议内的Log Compaction,并参考TiKV等实现,作者初步实现了分区快照与日志截断回收功能。
一、快照流程:
每个分区对应一个Raft组,由不同的Raft节点分布在集群的不同机器上,每个RaftNode都在循环处理Ready(如下图所示):

-
在达到快照创建条件时(上图步骤6),即满足一定周期(如6小时)且期间应用的已递交日志数量达到阈值(如10000条),RaftNode通知对应的状态机创建快照,这里主要是利用RocksDB的Snapshot及SstFileWriter将当前分区所涉及的KV数据写入相应的sst文件内。在状态机创建快照成功后,RaftNode通知对应的RaftStorage截断并回收日志,由于目前Raft日志同样使用RocksDB存储,所以可以利用RocksDB的DeleteRange功能批量删除无用的日志。
-
如果同一Raft组内的某一节点所在的机器Down机了较长的时间,在此期间此组内的Leader达到快照条件创建了快照并回收了日志。之后Down掉的机器重新启动,Follower与Leader通信后要求追加Down机期间的日志,但Leader快照前的日志已删除,Leader会发送Raft快照给Follower,这里需要注意的是Leader先发送状态机创建的各个sst文件,都发送完了再发送RaftSnapshot消息。
-
Follower在收到快照消息时(上图步骤3),先清理当前分区所涉及的所有旧数据,然后通知对应的状态机恢复快照数据,这里主要是利用RocksDB的IngestExternalFile将各个sst文件快速导入存储内。

本文介绍了AppBoxFuture中基于Raft一致性协议的快照流程和日志回收机制。当满足一定条件时,系统创建快照并利用RocksDB进行数据持久化,同时回收无用日志。在节点Down机后再恢复时,通过快照恢复数据。文章还提供了简单的测试步骤来验证快照和日志截断的功能。
最低0.47元/天 解锁文章
332

被折叠的 条评论
为什么被折叠?



