最近項目接觸到了redis cluster，現在趁着使用做一下總結，記錄一下遇到過的問題，簡單的概述一下常用到的命令和功能。
本篇文章主要是以運維的角度去講述如何去更好的規划redis cluster和跳坑。
redis cluster 官方文檔：
https://redis.io/topics/cluster-tutorial
一、redis cluster 是什么
redis cluster是官方redis 3.0版本之后推出的集群方案，之前類似的方案還有豌豆莢的codis集群方案、twemproxy方案，
不過twemproxy有個非常大的弊端就是不能在線擴容節點，這就比較尷尬了。redis cluster發布之后，截至目前為止，redis
cluster已經達到了成熟的程度，很多企業已經在生產系統使用，替換原有的twemproxy的分片方法。
二、redis cluster 的優點
- 支持數據分片功能，可以將數據分配到不同的實例上。
- 服務的高可用性、故障自動轉移，最大程度避免單點故障
- 在線水平擴展能力，可以在線添加節點，轉移數據等
- 無中心架構，各個節點度等。
- 降低原有的數據分片方案的復雜度，節省硬件資源
- 系統瓶頸更少，客戶端直連方式。
以上這些優點足以是我們選用redis cluster了。
三、redis cluster 應用最佳實踐（跳坑）
- 關於redis cluster實例的規划
為什么要用redis cluster呢，對於運維來講就是實現服務的高可用，避免單點故障。筆者遇到的最坑的就是前人創建的集群的時候沒有添加副本數，
是9台服務器上每台啟動24個實例，然后用這216個實例創建的一個cluster。直到上次其中的一台服務器內存故障，導致服務器down機，接着集群的部分
數據不可用，客戶服務受到了嚴重的影響。
創建集群的時候建議必須增加一個副本數，不然集群只是分片的作用，達不到高可用的要求。
redis是使用內存的數據庫，規划的時候可按照服務器的內存大小來規划，我們研發說單個實例建議最大設置為20G，是官方文檔中看到的，但是我還沒找到。
集群的最多節點建議是1000個。
筆者目前維護的最大的集群為： 30台512G內存服務器，每台服務器上啟動24個實例，共720個實例創建的一個cluster集群，副本數為1，相當於是360個
主和360個從節點。下圖為30台機器的內存已使用的監控和整體的匯總展示。
- 服務器數據的選擇
在服務器數據的選擇上，建議采用偶數數據的機器，原因如下：
假如選用redis cluster官方教程里面的方法，拿三台主機A、B、C，每台機器上啟動兩個實例，那么他們的主從關系則為：
A <----B1
A1 ---->B
C <----C1
沒錯，你會發現，C服務器自己是自己的從，那么問題來了，加入C服務器故障，那么你的數據還是丟失的，所以說你的架構上是存在問題，不是高可用，依然存在單點，此時假如你再增加一台服務器D，那么C和D則會交叉的進行主從關系。
當然，上面這個主從關系是使用redis創建集群工具時候默認的bug，如果你一定要三台，每台上啟動兩個這樣呢，你也可以這樣做：
先使用A\B\C創建集群，全部是主節點，然后手動添加從節點，這樣交叉添加也可以做到高可用。但是當你實例很多的時候你就力不從心了，所以建議采用偶數數目的服務器。
- 監聽地址需要注意的地方
在配置文件中bind地址的時候千萬不要用127.0.0.1,因為是要和其他服務器進行通信的，要采用真是的內網ip進行監聽，不然你的集群是創建不成功的。
- 不在支持多數據庫
根據官方文檔的描述，redis cluster 是不支持select db的，redis單實例的時候是支持多數據庫的。
- 參數優化
建議把cluster-require-full-coverage參數設置為no，即使單個slot異常，也不會出現大量的請求異常。
把cluster-node-timeout參數設置一個較小的值，比如6000（6秒）。這個參數建議不要設置太小或者太大，30s-60s即可。
以上便是在維護redis cluster的遇到的一些坑，分享給大家，希望大家提前避免。