redis cluster注意的問題 ：

1. ‘cluster-require-full-coverage’引數的設定。該引數是redis配置檔案中cluster模式的一個引數，從字面上基本就能看出它的作用：需要全部覆蓋！
   具體點是redis cluster需要16384個slot都正常的時候才能對外提供服務，換句話說，只要任何一個slot異常那麼整個cluster不對外提供服務。
   redis預設是‘yes’，即需要全覆蓋！建議設定成‘no’。

2. 阻塞命令產生failover。由於一些阻塞命令（flushall, del key1 key2 …）會造成redis在‘cluster-node-timeout’時間內無法響應其他節點的ping請求，
   從而導致其他節點都把該redis標記出了pfail狀態，進而產生failover。redis作者計劃使用lazy redis解決。

3. 連線建立。當redis cluster的節點數多了以後，client對每個節點建立一個tcp連線需要花比較多的時間。如果是長連線，使用者只需忍受一次連線建立的過程，
   如果是短連線，那麼頻繁建立連線將會極大的降低效率。但即便是短連線，只要每次請求只涉及到一個key，有些客戶端可能只需要與一個節點建立連線。

4. Jedis。Jedis是redis最流行的Java客戶端，支援redis cluster。
   ‘MaxRedirectionsException’異常，出現該異常說明剛剛執行的那條命令經過多次重試，沒有執行成功，需要使用者再次執行。
   在cluster擴容或者slot遷移的時候比較容易出現。建議捕獲該異常並採取相應重試工作。
   Pipeline，Jedis目前不支援cluster模式的pipeline，建議採用多併發代替pipeline。

5. Multi-key。Redis cluster對多key操作有限，要求命令中所有的key都屬於一個slot，才可以被執行。客戶端可以對multi-key命令進行拆分，再發給redis。
   另外一個侷限是，在slot遷移過程中，multi-key命令特別容易報錯(CROSSSLOT Keys in request don’t hash to the same slot)。建議不用multi-key命令。

6. 擴容速度慢。redis官方提供了redis cluster管理指令碼redis-trib.rb。使用該指令碼進行擴容cluster的時候，是序列的遷移slot中的每個key，這樣導致了
   擴容的速度非常慢，百G的資料要數小時。擴容時間越長，越容易出現異常。