一、 背景
随着业务的发展，线上Redis的数据越来越多，所以必须考虑扩容的事情了。对于redis的扩容，目前可选的方案有三种：1、client自己做sharding，一般是按key的hash值取模，对应到指定的redis server；2、采用redis3以上版本自带的cluster；3、Twitter开源的Twemproxy；4、国人开发的Codis。经过一番评估，我们决定采用Codis，原因不多说了，网上有很多。总结一句话：codis比较适合那种数据库比较大，但并发量不是特别高的系统。
二、 codis架构方案
Codis的原理和使用方法这里就不介绍了，网上有很多资料可以搜。这里说一下codis的proxy负载，有两种方案，如下：
方案一：通过HAProxy或F5来做负载均衡
方案优点：
1、 仍然可以使用Jedis作为客户端，原有系统的代码基本不用改
2、 方便扩容，扩容时代码基本无感知
方案缺点：
1、运维工作量增加，需要配置HA负载策略，并且每次扩容需要重新调整HA策略
方案二：通过Jodis客户端来做负载均衡
方案优点：
1、 简化运维
2、 少一个流程节点，降低了故障的概率
方案缺点：
1、 原有系统的代码全部需要修改，动作还是挺大的
2、 客户端依赖Jodis和zookeeper，相对比较重
备注：
如果使用Jodis客户端，jedis需要使用2.9.0及以上版本，同时spring-data-redis需要升级到1.5.0及以上版本。
我们最终选择的是第一个方案。主要是不用改已有的代码，否则研发人员会疯了。
三、 从Redis到Codis的上线步骤
2.1、上线步骤
1) 搭建生产环境下的codis集群，建议至少包括2个proxy、3个codis-server
2) 上线前：迁移redis数据到codis集群。数据迁移工具我们采用的是redis-port。Redis-port的使用和性能测试后续我再写文章介绍。需要注意的是：redis-port的sync操作，同步完成以后可以持续同步新写入的数据，切记不要关闭redis-port的sync进程，以保证codis集群的数据能够包括所有redis服务器的数据
3) 上线时，修改各个系统的redis连接信息，指向新codis集群，并重启服务
4) 观察各个系统是否运行正常
5) 观察原redis服务是否已经无请求接入
四、codis-HA
Codis-HA是codis提供的一个主从切换的工具，在codis3.1及以下版本中使用，codis3.2已经不推荐使用了，而是推荐使用sentinel。Codis-ha有几个问题：
1) 发生主从切换时，如果原来有多个slave，则没有提升为master的slave指向的master不会自动切换到新的master上
2) 被摘掉的master不会自动恢复，必须进行人工干预
综合来看，目前还是建议使用Sentinel + VIP的方式来实现主从切换。
五、报表监控
实时数据监控：
通过codis自带的控制台即可查看集群的实时数据，包括key数量、占用内存大小、实时请求数等
历史访问数据：
可以通过运维监控来实现，包括内存、CPU、IO、Load、请求数等的历史曲线，并可以设置监控报警
实时数据查询：
可以通过codis提供的restful api来实现，并嵌入到codis控制台中， 包括： 给定key，获得slot、group信息、以及最终数据，或者给定多个key，获得slot、group和最终数据
六、Codis后续扩容步骤
Codis可以实现在线不停服务进行扩容，具体的步骤如下：
1) 安装配置codis-server主从
2) 打开codis管理界面，新建server group、并添加刚刚安装的redis实例（注意：codis默认第一个添加的是master）
3) 规划slot分布，把部分slot迁移到新的server group中
说明：
3.1 slot迁移的过程中，Codis服务可以正常访问，codis的迁移机制可以保证数据的一致性
3.2 迁移时，key都是单个进行迁移，并且不能同时运行多个迁移任务，所以codis的迁移时间会比较长。一定要在扩容前留有足够的时间和空间。
七、参考资料
1、redis-port官网：https://github.com/CodisLabs/redis-port
2、codis-proxy不支持及部分支持的命令集
参见：https://github.com/CodisLabs/codis/blob/release3.2/doc/unsupported_cmds.md