redis-migration：独创的redis在线数据迁移工具

CarrieN40 9年前

来自： http://www.bitstech.net/2016/03/03/redis-migration/

一、常见redis数据迁移方式

业内，常见的redis数据迁移方式有以下三种：aof（日志文件）、rdb（快照文件）、replication（主从复制）。

其中，aof和rdb两种方式适用于跨网络（网络隔离）的redis实例之间的数据迁移，在源实例上通过指令（bgrewriteaof/bgsave）生成aof或者rdb文件 -> 下载数据文件 -> 上传数据文件 -> 启动目标实例，完成数据迁移。aof和rdb的差异，主要体现在数据格式和数据加载速度两个方面，前者是纯文本格式（redis文本协议的流水记录），加载的过程相当于历史重放，而后者是二进制格式，直接进行加载，所以一般情况下rdb数据加载会比aof加载快！这也是网上建议使用rdb做跨网络数据迁移的一个重要的原因。

  • aof

  • rdb

而replication方式，适用于同一网络内的redis实例之间的数据迁移，在目标实例上通过指令（slaveof）完成数据全量复制迁移，在单实例的扩容应用上最适合。

  • replication

二、开发redis-migration的需求

以上三种数据迁移方式都 只解决点对点的数据迁移 （缺陷1），而且aof和rdb还存在 增量数据不能同步 （缺陷2）的问题。

事实上，我们开发redis-migration这个工具的原始需求来自于网易私有云 redis集群的横向扩容 ：

  • redis集群横向扩容

三、如何开发redis-migration？

工具 定义

比较 前面三种数据迁移方式，思考能不能把replication（主从复制）的过程剥离出来做成一个独立工具呢？ 在连接源redis实例时候把自己模拟成slave，在连接目标redis实例（集群）时候把自己模拟成客户端，如下：

这样的话，源redis实例即使是分布式集群（多个源redis实例），也只需要同时启动多个迁移工具实例就能解决了，如下：

调研过程

定下开发迁移工具后，调研了如下的对象：

  1. redis-benchmark多客户端并发；
  2. redis replication交互过程；
  3. hiredis框架，报文组装和解析；
  4. RDB文件解析；
  5. AOF文件解析；

流程设计

下图是迁移工具的时序图，分为三部分：快照数据和增量数据，其中增量数据分为2个阶段，第1阶段会落地成文件，第二阶段不落地直接TCP转发。

编码实现

省略1万字，二进制文件： redis-migration ，源码后续放出。

技术难点

  1. 解析数据文件：包括AOF和RDB，相对而言解析AOF文件会简单些，它是文本格式的，按照redis协议纯文本处理即可；而RDB文件是二进制格式的，自己重新实现没这个必要，因为redis已经有解析RDB的接口，但源码是和redis本身是耦合在一起的，比如对各种共享对象、全局变量、数据结构dict/sds等的依赖，所以最后实现上变成了redis-benchmark.c和redis.c的结合体；
  2. 处理redis协议：解析来自数据源的redis数据，读取落地的RDB和AOF文件数据组装成redis协议数据。虽然客户端使用的还是hiredis库，但是请求和应答报文，都不能使用库提供的接口来组装和解析，需要重新实现，这一块工作量比较大。RDB和AOF的请求报文组装以及各自应答消息的解析与校验，其中RDB数据是二进制的，所以需要逐字段进行组装，hiredis库没有提供这样的接口，而且假设提供了也需要评估起性能；同时RDB数据里会设置key的有效时间，一条RDB数据可能需要组装成两条redis指令；两种数据都解析出类型后，用来精确判断应答消息的正确与否；
  3. 设计高效迁移：RDB数据有个特点，它保存的是每个key的快照，无时序要求，所以可以考虑并发发送的方式，提高迁移速度；而AOF数据，有时序要求，在目的地进行重放加载，不能并发，否则会乱序，出现数据错误，只能一个客户端发送，这时采用的是pipeline（批量）的方式；
  4. 方便调试定位：迁移工具和数据源、数据目的地的交互都是在线TCP流，而且都是瞬间完成的，对于中间的错误和异常，比较难以捕捉，现在的做法是在数据流入和流出的地方统一加了十六进制的报文日志；

功能特点

  1. 轻量级 ：仅增加了1个redis-migration.c文件，同时在Makefile文件中增加编译redis-migration二进制程序的2行指令；单线程，异步消息驱动模型，轻量化，工具编译出来约4M大小；
  2. 高性能 ：前面有人可能会好奇，单线程程序怎么实现多客户端并发？是这样的，因为一个客户端的请求是串行的，存在RTT这样一个时间窗口，那么在这个时间窗口里并发多个客户端就可以避免系统等待，极大提高性能；另外，AOF迁移时候使用了pipeline特性，批量发送，减少RTT来加速迁移；
  3. 低成本 ：迁移过程中的 数据都做了落地处理 ，工具本身没有对数据进行加载，内存开销就很小，这一点非常重要！
  4. 易操作：启动后，观察迁移进度日志即可；
工具价值
</div>

redis-migration迁移工具不仅可以解决外部实例迁往网易私有云redis集群、私有云redis集群横向扩容的问题，也可以解决外部redis集群的扩容问题， 具有通用价值 。比如：一个客户端分片的分布式redis集群，通过redis-migration工具（外加一个数据分片代理程序，比如twemproxy）将数据实时同步到新的集群，然后应用直接切到新集群上，集群横向扩容完成，中间不丢失任何数据！

</div>

应用案例

网易私有云线上已经有多个应用使用redis-migration进行了数据迁移，包括外部实例迁移、私有云分布式redis集群扩容等，下图为几个典型的应用：

另外，网易新闻客户端推荐系统约2T规模的redis数据，也将依赖redis-migration迁移到私有云redis集群上来，目前正处于资源准备阶段。

四、竞争对手

豌豆夹redis数据迁移工具

使用go语言实现，数据在线转发，没有落地，比较吃内存，经过简单测试发现迁移效率没有redis-migration高，源码见 ： https://github.com/CodisLabs/redis-port

腾讯云redis数据迁移工具

腾讯云redis数据迁移工具crs-port，居然是豌豆夹的二进制程序改了个名-_-##，下载地址： http://www.qcloud.com/wiki/%E4%BA%91%E5%AD%98%E5%82%A8Redis(CRS)%E6%95%B0%E6%8D%AE%E5%AF%BC%E5%85%A5

分布式系统的横向扩容历来是很难实现的，对redis集群这种纯内存数据库也不例外，而redis-migration迁移工具是对分布式redis集群横向扩容实现的一次实践，事实证明效果比较理想！

欢迎补充和测试。

</div> </div>

相关经验