参考的两篇文章，很赞~
http://www.jianshu.com/p/a5eec15de485
http://www.bitstech.net/2016/03/03/redis-migration/
简单来说，就是把自已伪装成 slave, 欺骗master来达到数据流同步的目地
发送sync命令->接收rdb->解析rdb->过滤->回放rdb->回放master推送的同步数据
流程设计
迁移过程整体上可以分为三个部分：快照数据和增量数据，其中增量数据分为2个阶段，第1阶段会落地成文件，第二阶段不落地直接TCP转发：
技术难点
解析数据文件：包括AOF和RDB，相对而言解析AOF文件会简单些，它是文本格式的，按照redis协议纯文本处理即可；而RDB文件是二进制格式的，自己重新实现没这个必要，因为redis已经有解析RDB的接口，但源码是和redis本身是耦合在一起的，比如对各种共享对象、全局变量、数据结构dict/sds等的依赖，所以最后实现上变成了redis-benchmark.c和redis.c的结合体；
处理redis协议：解析来自数据源的redis数据，读取落地的RDB和AOF文件数据组装成redis协议数据。虽然客户端使用的还是hiredis库，但是请求和应答报文，都不能使用库提供的接口来组装和解析，需要重新实现，这一块工作量比较大。RDB和AOF的请求报文组装以及各自应答消息的解析与校验，其中RDB数据是二进制的，所以需要逐字段进行组装，hiredis库没有提供这样的接口，而且假设提供了也需要评估起性能；同时RDB数据里会设置key的有效时间，一条RDB数据可能需要组装成两条redis指令；两种数据都解析出类型后，用来精确判断应答消息的正确与否；
设计高效迁移：RDB数据有个特点，它保存的是每个key的快照，无时序要求，所以可以考虑并发发送的方式，提高迁移速度；而AOF数据，有时序要求，在目的地进行重放加载，不能并发，否则会乱序，出现数据错误，只能一个客户端发送，这时采用的是pipeline（批量）的方式；
方便调试定位：迁移工具和数据源、数据目的地的交互都是在线TCP流，而且都是瞬间完成的，对于中间的错误和异常，比较难以捕捉，现在的做法是在数据流入和流出的地方统一加了十六进制的报文日志；
功能特点
轻量级：仅增加了1个redis-migration.c文件，同时在Makefile文件中增加编译redis-migration二进制程序的2行指令；单线程，异步消息驱动模型，轻量化，工具编译出来约4M大小；
高性能：前面有人可能会好奇，单线程程序怎么实现多客户端并发？是这样的，因为一个客户端的请求是串行的，存在RTT这样一个时间窗口，那么在这个时间窗口里并发多个客户端就可以避免系统等待，极大提高性能；另外，AOF迁移时候使用了pipeline特性，批量发送，减少RTT来加速迁移；
低成本：迁移过程中的数据都做了落地处理，工具本身没有对数据进行加载，内存开销就很小，这一点非常重要！
易操作：启动后，观察迁移进度日志即可；
同行比较
豌豆夹redis数据迁移工具
redis-port，使用go语言实现，但只支持redis到codis的迁移，源码 ：https://github.com/CodisLabs/redis-port
腾讯云redis数据迁移工具
crs-port，使用上和redis-port一致（包括日志信息），没有落地，比较吃内存，简单测试效率没有redis-migration高，下载地址：
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集群横向扩容实现的一次实践，事实证明效果比较理想！
360中redis迁移到pika工具
基于aof文件做的迁移
微博版本redis迁移工具
基于rdb+aof方式实现快照和增量迁移
