DCache-CacheServer分析（四）

2019年12月10日

本文介绍CacheServer中CreateBinlogFileThread线程和BackUpImp的相关配置和处理逻辑

CreateBinlogFileThread

功能：用于定时生成binlog文件。

binlog文件按模块(表)划分，里面记录了对该模块的所有增量操作，主要用于主从数据同步和故障恢复，类似于redis中的AOF。DCache的binlog分为2种：key-binlog和正常的binlog，按需开启。

相关文件：

TimerThread.h
TimerThread.cpp

配置解析

<BinLog>
    #binlog日志文件名后缀
    LogFile=binlog
    #每次同步binlog的行数
    MaxLine=10000
    #是否记录binlog
    Record=Y
    #是否记录key binlog
    KeyRecord=N
    #主备同步使用key binlog
    KeySyncMode=N
    #同步binlog是否开启压缩
    SyncCompress=Y
    #采用gzip压缩格式
    IsGzip=Y

    #备机同步binlog缓存buffer的szie
    BuffSize=10
    #保存synctime文件的间隔(秒)
    SaveSyncTimeInterval=10
    #active binlog产生的周期(秒)
    HeartbeatInterval=600
</BinLog>

该线程只读取以下配置：

LogFile	binlog日志文件名后缀，一般情况下不会修改这个参数。 binlog文件只存放在CacheServer所在的主机上，不会写到远程日志中心。 如：DCache.BillAppCacheAMLTMKVCacheServer1-1_binlog_2022042921.log
Record	是否记录binlog
KeyRecord	是否记录key binlog。 在某些不关注value的场景中，可以只写key binlog。正常情况下用不到，保持关闭即可

线程逻辑

1、如果既不写普通binlog（Record=N），也不写keybinlog（KeySyncMode=N），线程就直接退出。

2、线程每秒执行1次

3、每小时生成1个binlog文件

4、binlog文件都放在在该服务的日志路径下，keybinlog和binlog文件名不一样，keybinlog在”LogFile”配置的后面多了”key”

---

BackUpImp

功能：提供DCache数据的全量备份和恢复服务

说明：当前框架中并无客户端调用该服务，需要视情况调用。

对象名称：

DCache.FeeAppVRecvListMKVCacheServer1-1.BackUpObj

相关文件：

MKBackUpImp.h
MKBackUpImp.cpp

接口说明

MKBackUp.tars：

module DCache

{
interface MKBackUp

{
/*
* dump内存数据到指定路径文件
* dumpPath: 存放镜像文件的绝对路径，如果为空则dump到默认路径:/data/dcache/dump_binlog/
* mirrorName: 镜像文件名, 如果为空则使用组名和当前时间生成文件名，例如:TestModuleMKVGroup1_dump_binlog_20190701120101.log.gz
*/
int dump(string dumpPath, string mirrorName, out string errmsg);



/*
* 恢复mirror和binlog，路径下没有mirror，则只恢复binlog，有的话先恢复mirror，再恢复binlog
* mirrorPath: mirror文件绝对路径
* binlogPath: binlog文件绝对路径
* lastTime: 恢复到该时间点，unix时间戳，精度：秒
* normal:是否强制恢复，正常的恢复流程在加载完镜像和binlog后，会再从主机同步一条binlog
* 强制恢复流程，则是加载完镜像和binlog后，就认为恢复完成
*/
int restore(string mirrorPath, vector<string>binlogPath, int lastTime, bool normal, out string errmsg);

};
};

该服务提供了2个方法，在MKBackUp.tars文件中有方法功能的详细说明。

1、dump方法

启动1个DumpThread线程，进行数据的备份（详细逻辑，见《CacheServer-DumpThread》）。

2、restore方法

初始化并启动1个SlaveCreateThread线程，进行数据恢复。（详细逻辑见《CacheServer-SlaveCreateThread》）

DCache在服务层并未集成“自动故障恢复”相关功能，但为我们提供了对应的rpc服务，让使用者决定是否备份、何时备份，以及数据恢复的粒度，在操作上更加灵活。

在我的项目实践中，编写了一个job挂载到Tars上：

• 每1小时执行一次dump，全量备份内存数据（间隔可配置，视情况而定），记录时间戳T
• 增加自定义指令restoreAll，作用是恢复全量数据和增量操作到内存中。在指令处理中，读取最近一次的dump文件和时间戳T，进行restore；完成之后再处理时间戳T之后的binlog文件，恢复dump之后的操作

这样，如果系统宕机，也可以通过在控制台上执行指令“restoreAll”，来快速恢复内存数据。

当然，恢复过程也完全可以做到自动化：定时到注册中心查询DCache模块的服务列表，发现哪个模块异常后，再主动探测几次，确认异常之后进行标记。待该模块恢复之后，自动发起“restoreAll”操作。 

---

总结

DCache也具备全量备份和增量备份的功能，具备故障恢复数据的能力。

但与Redis不同，DCache的全量备份是由开发者编码控制的(调用DCache接口)，增量备份是DCache自动完成的；恢复数据时，也需要通过编码调用DCache相应的接口来实现。

DCache之所以这样处理，笔者认为是因为DCache使用的共享内存，即使进程意外挂死，内存数据还在。这时重启CacheServer即可，并不需要重“数据预热”的过程，处理能力恢复的更快！

只有在主机宕机的情况下，才需要调用接口来恢复数据。