欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

AppBoxFuture: Raft快照及日志截断回收

程序员文章站 2022-05-18 20:26:01
  AppBoxFuture的存储引擎依赖Raft一致性协议来保证各个分区副本的一致性,如果不处理Raft日志将不断增长,因此需要特定的机制(定期或每处理一定数量的日志)来回收那些无用的日志数据。通过学习Raft协议内的Log Compaction,并参考TiKV等实现,作者初步 ......

  appboxfuture的存储引擎依赖raft一致性协议来保证各个分区副本的一致性,如果不处理raft日志将不断增长,因此需要特定的机制(定期或每处理一定数量的日志)来回收那些无用的日志数据。通过学习raft协议内的log compaction,并参考tikv等实现,作者初步实现了分区快照与日志截断回收功能。

一、快照流程:

  每个分区对应一个raft组,由不同的raft节点分布在集群的不同机器上,每个raftnode都在循环处理ready(如下图所示):
AppBoxFuture: Raft快照及日志截断回收

  • 在达到快照创建条件时(上图步骤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文件快速导入存储内。

创建与接收的快照文件目前存储在运行时snapshot目录内。

二、简单测试:

1. 启动集群并新建测试用实体模型

参考前篇“告别单体架构,迎接分布式时代”启动一个新集群,并且登录至ide创建新实体。

2. 关闭集群某一节点模拟down机

直接control+c关闭某一节点。

3. 新建一个服务插入5000条记录

在ide内新建服务用于插入5000条记录(用于触发快照条件),调用此服务后可看到控制台输出如下图所示的创建快照日志。
AppBoxFuture: Raft快照及日志截断回收

4. 重新启动down机节点

通过如下命令重启down机节点,可看到控制台输出如下图所示的恢复快照日志。

sudo ./appbox

AppBoxFuture: Raft快照及日志截断回收

5. 验证down机节点快照恢复

通过tools/dbscan工具查看快照数据是否已恢复。

tools/dbscan --db=data(数据所在目录) --cf=tablecf --take=10000 --prefix=000020017000

dbscan的参数--prefix=十六进制字串, 可以只匹配相同前缀的kv记录

三、本篇小结:

  本篇介绍了raft快照及日志截断回收的流程及相应的测试,github上的运行时已更新可供测试。作者单独开发appboxfuture到十月一日就整一年了,期间曾多次想放弃,好在顶着巨大的压力总算解决了这最后一个技术难点,到此基本上原型验证是没有大问题了,下一步的重点是完善必要功能、稳定性及性能优化,并且考虑是开源该项目还是商业化运作。