亿级redis数据导出与导入

背景

我们线上有一个redis-sentinel集群，随着数据量的增大，识别到redis容量近期会达到瓶颈，稳定性也有很大的风险，两台redis机器rdb进程随时都在进行全量备份，一直暂用100%的cpu，当下次有大量数据写入的时候，比如每秒10000个数据持续写入，rdb备份势必会失败，按照官网所说，redis maxmemory配置到32g以上是不会带来效率和稳定性的增强，为了规避风险，需要将redis 主从模式切换到redis cluster模式，实现redis的横向扩容。

集群：3台sentinel，2台redis（一主一从）

配置：master 128gb，执行rdb备份，maxmemory 104gb

数据量：Redis一个db中有4.6亿条hashmap类型的数据，现在redis暂用内存66%左右

 

需求

1. 老redis 4.6亿数据迁移到新的redis 集群，1天之内迁移完

2. 老redis必须运行正常，服务0中断，不影响业务

3. 预计支持10+亿条数据查询

4. 自动化部署和cluster 扩容

设计

考虑的点：
    1.集群配置
    2.数据是否采用压缩
    3.数据的临界值
    4.写入速度
    5.备份方式
    6.集群状态

部署设计：十台6c32g centos7.3机器，每个机器上部署两个redis实例，总共20个实例，每个实例配置maxmemory 14g，预计最少可以支持7亿条我们最大样本数据，每台机器上的实例交叉互为主从，相互互为主从的实例不在同一台机器上。部署我们采用ambari框架，自己实现custom service。

数据导出设计：自己写程序，使用redis scan pipepline（每次10000条）的形式，同时开启两个线程向老redis的slave取数据，数据导出到16个文件，格式为json，每行一个json。

数据导入设计：自己写程序，按文件来开启16个线程，同时向新的redis cluster写数据。

总结

1 集群规模
数据边界值：老redis 4.6亿条数据估算约占用60G（加上redis额外开销），原预估redis cluster分片总内存96G（没算从节点）可满足要求，但是经过测试，redis分片集群对数据的额外开销大的多，14G左右的内存存储的上限大概7000万条（单条数据占用内存140Bytes）。
redis内存设置：redis不适合单机大内存配置，32G后性能不会增加
解决方法：采用单机器双实例部署的模式（总共10台机器），机器之间交叉互为主从
 单台机器双实例模式，单机器32G跑两个redis，每个redis maxmemory 14G，总共10台32G虚拟机，cpu升到6核（我们开启了rdb和aof备份，一个实例最多需要占用3个cpu）
    2. 数据迁移
     老redis 4.6亿条数据迁移到redis 分片集群，执行的过程为：
（1）老redis数据导出到磁盘，考虑的点:
 不影响老redis集群提供服务的能力
 时间不超过半天
解决方法：
访问slave导出数据，通过scan来取数据，导出到16个文件中，每次取出10000条数据，开启两个线程循环开跑，slave cpu使用率始终70%左右，峰值不超过90%，6个小时左右跑完
（2）数据导入到redis cluster分片
开启16个线程同时读取16个文件，采用Buff的形式读取，每100000条pipeline一次到redis分片集群，观察到整个集群每秒的写入数据量大概是1.5W/s，大约两个小时导完（其中有网络和redis处理延迟时间开销在里面）
（3）备份策略
     之前开启的rdb备份，发现单台机器4000万左右数据量的时候redis出现rdb备份失败导致服务不可用，原因是大量数据写入的时候，根据rdb save策略，每秒有10000的写入时候会进行全量备份，导致机器一直在备份，备份进程占用cpu始终100%，最后导致备份失败。
解决方法：导入的过程中关闭aof和rdb备份功能，导入完成后开启rdb和aof功能

测试数据：
数据临界值：
    测试场景: 10台虚拟机，每台机器6c32g，redis单实例maxmemory 14g，大量写入，
    测试结果：
            (1)4.6亿条数据导入费时2h 10min左右（生成环境实际不到2个小时），分到10台虚拟机每台大概4600万，此时占用系统内存35%，分配给redis的上限是14gb约为系统的43%左右
            (2)内存14g存储的数据量临界值约为7000万，如果此时整个集群有大量的写入会平凡出现slave掉线

            (3)整个过程执行导入导出的机器没有考虑磁盘io，使用iostat发现完全能抗住。

我们没有采用网上开源的工具是因为：

1. 导出太慢，例如redisdump

2. 不支持redis选择db，只能整个，例如：redis-migrate-tool

3. 不支持数据过滤与修改，例如我们导出后的key是需要在导入的时候加上业务前缀标识的