監聽 截至目前 實踐 啟動 但是 -- 是什麽 size 發現

最近項目接觸到了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 的優點

1. 支持數據分片功能，可以將數據分配到不同的實例上。
2. 服務的高可用性、故障自動轉移，最大程度避免單點故障
3. 在線水平擴展能力，可以在線添加節點，轉移數據等
4. 無中心架構，各個節點度等。
5. 降低原有的數據分片方案的復雜度，節省硬件資源
6. 系統瓶頸更少，客戶端直連方式。

以上這些優點足以是我們選用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的遇到的一些坑，分享給大家，希望大家提前避免。

redis cluster 實踐總結