Redis應用學習——Redis Cluster運維常見問題

1. 集羣完整性

    1. 在每一個節點的配置文件中有一個配置參數cluster-require-full-coverage，默認值爲yes，該參數就表示是否要保證集羣中16384個槽位所有可用時，該集羣纔會提供服務，即要保證集羣的完整性；參數值設置爲yes，則若是某個持有槽位的節點發生故障或者正在故障轉移，客戶端執行key命令時就會返回客戶端一個error錯誤，提示該集羣已下線中止服務，因此通常來講，在實際應用中是沒法容忍參數值爲yes，通常都會設置爲no

2. 帶寬消耗

    1. Redis Cluster中的節點數量不超過1000個（官方建議），由於每一個節點之間都會定時進行一些信息交換（好比節點狀態監測、進行ping/pong操做等），當節點數量擴大時，就會帶來不容忽視的帶寬消耗，影響帶寬消耗主要在下列三個方面：

（1）消息發送頻率：節點發現與其餘節點的最後一次通訊時間超過cluster-node-timeout/2時，會向其餘節點發送ping命令

（2）消息數據量：好比會接收slot槽位數組和整個集羣的狀態數據

（3）節點部署的機器規模：集羣部署的機器規模越大，且每臺機器的節點部署的越均勻，則集羣總體可用寬帶會提升

    2. 優化方法：

（1）避免多個業務使用一個集羣，大業務可使用多個集羣

（2）儘可能將節點均勻部署到多臺機器中

（3）合理配置參數cluster-node-timeout

3. pub/sub廣播

    1. 發佈訂閱在集羣中的影響：當經過某個節點的客戶端發佈一條消息，那麼該節點會自動向集羣中的其餘節點發布消息，不管其餘節點是否訂閱了該節點發布消息的頻道，這就致使帶寬消耗。能夠單獨寫一套Redis Sentinel來解決

4. 集羣傾斜

    1. 數據傾斜：簡單來講就是槽位或者說節點之間的數據量差別較大，一般由如下四個緣由形成

（1）節點與槽位的分配不均勻，能夠經過 redis-trib.rb info ip:port，該命令來查看集羣全部主節點的節點、槽位與鍵值的分佈

（2）各個槽位中的數據量差別大，在前面說過能夠經過在key以前添加一個hash_tag能夠保證批量命令的執行能夠在同一個節點上，這就會致使數據傾斜

（3）包含bigkey，即key所對應的value數據量極大，好比大字符串，具備大量元素的list、set等類型的數據，這時就須要優化數據結構

（4）內存相關配置不一致

    2. 請求傾斜：也就是熱點key問題，某個key是一個極高訪問頻率的key，或者該key是一個bigkey

5. 讀寫分離

    1. 集羣模式的從節點不接受任何讀寫請求，某個客戶端鏈接到從節點進行讀寫操做時會重定向到其主節點上進行讀寫操做，而經過一個readonly命令就可使從節點實現，在鏈接到從節點的客戶端上進行讀操做時必須先執行命令readonly，而後才能進行讀操做

    2. 集羣模式中實現讀寫分離面臨的問題與Redis Sentinel中相同，可是集羣中實現讀寫分離更爲複雜，因此不建議實現讀寫分離，一般是在集羣中部署多個節點來減輕讀寫壓力

6. 數據遷移

    1. 經過官方集羣管理工具redis-trib.rb將單機節點的數據遷移到集羣中：命令爲 redis-trib.rb  import  host:port   --from <arg>，host與port參數寫集羣中的一個節點的IP地址與端口，而arg參數則要寫單機節點的IP地址與端口，形式也是host:port，該命令只能將數據從單機節點遷移到集羣中，並且不支持在線遷移（也就是源節點一邊寫入數據一邊進行遷移數據），不支持斷點續傳（也就是沒法從上一次遷移中斷的地方繼續遷移）