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，該命令只能將數據從單機節點遷移到集羣中，而且不支持在線遷移（也就是源節點一邊寫入數據一邊進行遷移數據），不支持斷點續傳（也就是無法從上一次遷移中斷的地方繼續遷移）