RedisSyncer 中采用链式策略处理同步数据

RedisSyncer 使用 replid 和 offset 实现断点续传,避免数据不一致。v2 版本引入事务处理,通过 multi-exec 包装命令,确保一致性。在目标 Redis 的每个逻辑库中写入 checkpoint,选取最大 offset 作为续传参数。同时,具备数据补偿机制,处理写入失败的情况,并采用断线重连机制,保证源端和目标端连接的稳定性。通过链式策略处理同步数据,确保所有策略通过才同步 key 到目标 Redis。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

RedisSyncer 的断点续传机制是基于 Redis 的 replid 和 offset 来实现的,RedisSyncer 有两个版本的断点续传机制 v1 和 v2。

  • v1 版本:

v1 版本数据写入到目的端 redis 后,将 offset 持久化到本地,这样下次重启就从上次的 offset 拉取。但是由于该方案写目的端的操作和 offset 持久化不是一个原子的操作。如果中间发生中断会导致数据的不一致。 例如,先写入数据到目的端成功,后持久化 offset 还没成功就发生了宕机、重启等情况,那么再次断点续传拉取上一次的 offset 数据最后就不一致了。  

  • v2 版本:

在 v2 版本策略中 RedisSyncer 会将每一个 pipeline 批次中不存在事务的的命令通过 multi 和 exec 进行包装,并在事务尾部插入 offset 检查点。 当断点续传时需要从目标 Redis 的所以 db 库中查找 checkpoint 并找到所对应源节点当最大 offset,再根据该 offset 进行断点续传。目前 v2 版本只支持目标为单机 Redis 的情况。 在 v2 版本中

  • v2 命令事务封装结构

  • v2 checkpoint 检查点结构:

    HASH  hset redis-syncer-checkpoint {value}
    {value}:
        * {ip}:{port}-runid     {replid}
        * {ip}:{port}-offset    {offset}
        * pointcheckVersion     {version}

在 Redis 的事务机制中虽然不支持回滚,并且如果事务中间命令执行出错后但是事务还是被执行完成,但是除特殊情况外能够保证一致性。 在 v2 的机制中,为了防止 ' 写放大 ' 会在目标 redis 的每一个逻辑库中写入一个 checkpoint,因此在执行断点续传操作的时候,同步工具会先扫描目标各个逻辑库中的 checkpoint 并选出里面最大 offset 的 checkpoint 作为断点续传的参数。  

数据补偿机制

在数据同步过程中,存在由于网络稳定性或其他因素导致 key 写入失败的情况,为此 redissyncer 实现了一套补偿机制来保证源端与目的端数据的一致性。 数据补偿的前提是命令写入的幂等性,因此在 RedisSyncer 中会先将 INCR、INCRBY、INCRBYFLOAT、APPEND、DECR、DECRBY 等部分非幂等命令转换成幂等命令后再写入目标端 Redis。 RedisSyncer 在目标为单机 Redis 或者 Proxy 的时候是通过 pipeline 机制将数据写入到目标 Redis 中的,每一个批次的 pipeline 的提交会返回一个结果列表, 同步工具会验证 pipeline 中结果的正确性,如果部分命令写入失败,同步工具对该批次与该 key 相关的命令进行重试。 如果重试超过指定的阀值,将会宕掉任务。对于存在大 key 的 list 等非幂等结构,将不会进行数据补偿,强制结束任务待人工处理。

断线重连机制

 由于网络抖动等原因可能会导致同步工具源端与目标端连接在同步过程中断开,因此需要断线重试机制来保证在任务同步的过程中如果出现异常断开的问题。断线重连机制存在于与源 Redis 节点和 RedisSyncer、RedisSyncer 与目标 Redis 节点的连接之间,两者分别有各自的处理机制。  

  • 源端重连机制

    源 Redis 与 RedisSyncer 的断线重连机制是通过记录的 offset 来实现的,当因网络异常等原因断开了连接时,RedisSyncer 会重新尝试与源 Redis 节点建立连接,并通过当前任务记录的 runid、offset 等信息去拉取断开之前的增量数据,连接重新建立成功后 RedisSyncer 的同步任务将会无感知继续同步。当断线重连超过指定重试阀值或者因为 offset 刷过导致没有办法续传数据时,RedisSyncer 会宕掉当前当同步任务,等待人工干预。

  • 目标端重连机制

    RedisSyncer 与目标 Redis 之间的断线重连机制是通过缓存上一批次的 pipeline 的命令来实现的,当连接断开异常时 RedisSyncer 进行重重连回放上一批次写入失败的命令。当回放失败或者超过连续重试次数 RedisSyncer 会宕掉当前当同步任务,等待人工干预。

命令的链式处理

RedisSyncer 中采用链式策略处理同步数据,任何一个策略返回失败,该 key 都将不会被同步。链式策略流程如图所示

 每一个 key 在 RedisSyncer 都会经过一个策略链进行处理,只要有一个策略未通过则这个 key 将不会同步到目标 Redis,比如 key 过期时间的计算策略如果计算出全量阶段 key 已过期,则将会自动抛弃该 key。

策略链中的策略包括

类型策略描述
DataAnalysisStrategy命令统计分析
KeyFilterStrategy命令过滤
DbMappingStrategyDb 映射
TimeCalculationStrategy过期时间计算
RdbCommandSendStrategy全量数据写入
AofCommandSendStrategy增量数据写入
..........
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值