一、 背景
隨着業務的發展，線上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