公司的redis服务器key的数量以达到千万级别，需要对redis进行实例拆分并线上迁移redis数据。
之前公司用的迁移脚本是基于一个key一个key的，速度非常慢，脚本如下：
#!/bin/bash
#redis 源ip
src_ip=192.168.1.1
#redis 源port
src_port=6379
#redis 目的ip
dest_ip=192.168.1.1
#redis 目的port
dest_port=9379
#src redis pass
src_auth_pass=Idianyou_Redis6379
#dest redis pass
dest_auth_pass=Idianyou_Redis6379
#要迁移的key前缀
key_prefix=circle
#迁到那个db
dest_db=0
#设置ttl过期时间
TTL=0
i=1
Cmd=/zywa/redis/bin
Other_Cmd=/zywa/redis_9379/bin
$Cmd/redis-cli -h $src_ip -p $src_port -n 0 -a $src_auth_pass keys "${key_prefix}*" | while read key
do
$Cmd/redis-cli -h $src_ip -p $src_port -n 0 -a $src_auth_pass --raw dump $key | perl -pe 'chomp if eof' | $Other_Cmd/redis-cli -h $dest_ip -p $dest_port -a $dest_auth_pass -n $dest_db -x restore $key 0
echo "$i migrate key $key"
((i++))
done于是，通过查阅资料，最后决定使用唯品会开发的开源的redis迁移工具：redis-migrate-tool。该项目已在github上开源。一下称为RMT。
该工具的优势：
快速。
多线程。
基于redis复制。
实时迁移。
迁移过程中，源集群不影响对外提供服务。
异构迁移。
支持Twemproxy集群，redis cluster集群，rdb文件 和 aof文件。
过滤功能。
当目标集群是Twemproxy，数据会跳过Twemproxy直接导入到后端的redis。
迁移状态显示。
完善的数据抽样校验。
RMT支持异构redis相互之间的迁移，数据来源可以是：单独的redis实例，twemproxy集群，redis cluster，rdb文件，aof文件。目标可以是：单独的redis实例，twemproxy集群，redis cluster，rdb文件。
RMT启动后模拟成redis slave，请求master的全量数据和增量数据。RMT收到数据之后解析成redis协议格式的oplog（写操作），然后发送给目标库。有两种请求方式，source_safe: true，对于同一ip上的redis，逐个的请求全量数据（RDB）；source_safe: false，并行请求同步全量数据。source_safe: false时，需要注意多个源redis所在的同一主机是否有足够的内存和RDB并发落盘时的IOPS性能。
RMT可以帮你从备份的AOF和RDB文件恢复到目标库。
RMT安装步骤：
依赖：
yum -y install automake
yum -y install libtool
yum -y install autoconf
yum -y install bzip2
安装redis-migrate-tool
unzip redis-migrate-tool-master.zip
cd redis-migrate-tool-master
autoreconf -fvi
./configure
make
检查安装是否成功，如下图所示即为正确
src/redis-migrate-tool -h
参数说明：
-d 以守护进程执行
-I 输出有用的信息
-n 不接收目标redis的回应
-v 设置日志等级，默认5，最小0，最大11
-o 输出到日志
-c 配置文件
-p 进程文件，默认没有
-m 存储器缓冲大小，默认512字节，和机器磁盘一个扇区一样，我猜的
-C 默认redis_migrate，就是迁移命令
-r 源类型，默认single，还可以是twemproxy或者redis_cluster
-R 目标类型，默认single，还可以是twemproxy或者redis_cluster
-T 线程数，使用多少线程来跑这个job，默认1
-b 默认可以使用128T的缓存来运行这个job
-f 源ip:port
-t 目标ip:port
-S 默认1，用于解析请求的步骤，数值越大，迁移越快，内存占用也就越大
使用：
cd /root/redis-migrate-tool-master
vim rmt.conf
[source]
type: single
servers :
-192.168.1.11:6379
redis_auth:数据库密码
[target]
type: single
servers:
-192.168.1.11:7379
redis_auth:数据库密码
[common]
listen: 0.0.0.0:8888
threads:8
filter:test*
以上文件说明：将192.168.1.11上端口为6379的redis中 以test开头的key迁移至端口为7379的redis中。
执行程序：
cd /root/redis-migrate-tool-master
./src/redis-migrate-tool -c rmt.conf -o log -d && date
执行 taif log
[2019-02-20 10:13:56.801] rmt_redis.c:1623 MASTER <-> SLAVE sync: RDB data for node[192.168.1.11:6379] is received, used: 166 s
[2019-02-20 10:13:56.802] rmt_redis.c:1643 rdb file node192.168.1.11:6379-1550628670699842-6771.rdb write complete
[2019-02-20 10:14:00.188] rmt_redis.c:6601 Rdb file for node[192.168.1.11:6379] parsed finished, use: 2 s.
[2019-02-20 10:14:00.397] rmt_redis.c:6709 All nodes' rdb file parsed finished for this write thread(0).
出现以上信息时，说明迁移完成。
状态查看：通过redis-cli连接redis-migrate-tool监控的端口，运行info命令
redis-cli -h 192.168.1.11 -p 8888验证：
抽样验证
./src/redis-migrate-tool -c rmt.conf -o log -C redis_check 10000 #默认抽样1000个key
Check job is running...
Checked keys: 1000
Inconsistent value keys: 0
Inconsistent expire keys : 0
Other check error keys: 0
Checked OK keys: 1000
All keys checked OK!
Check job finished, used 9.755s
注意事项：
1、重要的事说三遍，RMT迁移数据到twemproxy，需要保持rmt.conf 中 [target] hash、distribution、servers 三个参数和目标集群的twemproxy配置严格一致。
2、迁移中和业务切换之前，请反复观察“-o rmt.log”日志信息，确认是否有异常。
3、业务切换之前，请充分检查，特别是数据的一致性。
4、RMT 建议部署在单独空闲机器上，同目的集群在同一个网段（跨机房迁移数据，可以提高迁移速度）。千万不要部署在源集群所在的机器，防止资源不足，比如内存，带宽，IOPS。
5、注意RDB传输是否超时；
6、redis client buf中的slave项，设置足够大的buffer size和超时时间。
升级改造1（改变target的db库号）：
此工具会将source的所有库（db0-db115）的被过滤的key都迁移到taraget的0号库。显然是由问题的，可能会造成一些key的覆盖。通过查阅资料，现在只能修改target的库号。
修改rmt_core.c文件，在426行添加如下代码：
log_stdout("---------> write select command to target");
rmt_send_sync_cmd_read_line(tc->sd, "SELECT", "10", NULL); // the target redis db然后重新 make，会将所有选定的key迁移到target的10库中。
升级改造2（将指定前缀的key从source的对应库号迁移到target的对应库号）：
将之前的redis-migrate-too彻底删除，然后从以下地址重新下载并重新按之前的步骤解压安装即可。
https://github.com/silence0607/redis-migrate-tool
效率测试结果：
用最早之前的脚本，迁移是基于一个一个迁移的。几百万的key一次迁移要花费6个小时以上。使用RMT迁移工具，54万的key只需要三分钟即可迁移完毕。完成效率根本不在一个级别。
参考博客：
http://www.mamicode.com/info-detail-2437802.html
github开源地址：