Redis Cluster 不保證強一致性，在一些特殊場景，客戶端即使收到了寫入確認，還是可能丟數據的。

場景1：異步復制

• client 寫入 master B
• master B 回復 OK
• master B 同步至 slave B1 B2 B3

B 沒有等待 B1 B2 B3 的確認就回復了 client，如果在 slave 同步完成之前，master 宕機了，其中一個 slave 會被選為 master，這時之前 client 寫入的數據就丟了。

wait 命令可以增強這種場景的數據安全性。

wait 會阻塞當前 client 直到之前的寫操作被指定數量的 slave 同步成功。

wait 可以提高數據的安全性，但并不保證強一致性。

因為即使使用了這種同步復制方式，也存在特殊情況：一個沒有完成同步的 slave 被選舉為了 master。

場景2：網絡分區

6個節點 A, B, C, A1, B1, C1，3個master，3個slave，還有一個client，Z1。

發生網絡分區之后，形成了2個區，A, C, A1, B1, C1 和 B Z1。

這時 Z1 還是可以向 B 寫入的，如果短時間內分區就恢復了，那就沒問題，整個集群繼續正常工作，但如果時間一長，B1 就會成為所在分區的 master，Z1 寫入 B 的數據就丟了。

maximum window（最大時間窗口） 可以減少數據損失，可以控制 Z1 向 B 寫入的總數：

過去一定時間后，分區的多數邊就會進行選舉，slave 成為 master，這時分區少數邊的 master 就會拒絕接收寫請求。

這個時間量是非常重要的，稱為節點過期時間。

一個 master 在達到過期時間后，就被認為是故障的，進入 error 狀態，停止接收寫請求，可以被 slave 取代。

小結

Redis Cluster 不保證強一致性，存在丟失數據的場景：

• 異步復制

在 master 寫成功，但 slave 同步完成之前，master 宕機了，slave 變為 master，數據丟失。

wait 命令可以給為同步復制，但也無法完全保證數據不丟，而且影響性能。

• 網絡分區

分區后一個 master 繼續接收寫請求，分區恢復后這個 master 可能會變為 slave，那么之前寫入的數據就丟了。

可以設置節點過期時間，減少 master 在分區期間接收的寫入數量，降低數據丟失的損失。

推薦學習：《redis教程》