一、數據丟失的情況

異步復制同步丟失

集群產生腦裂數據丟失

1.異步復制丟失

對于redis主節點與從節點之間的數據復制，是異步復制的，當客戶端發送寫請求給master節點的時候，客戶端會返回ok，然后同步到各個slave節點中。

如果此時master還沒來得及同步給slave節點時發生宕機，那么master內存中的數據會丟失；

要是master中開啟持久化設置數據可不可以保證不丟失呢？答案是否定的。在master 發生宕機后，sentinel集群檢測到master發生故障，重新選舉新的master，如果舊的master在故障恢復后重啟，那么此時它需要同步新master的數據，此時新的master的數據是空的（假設這段時間中沒有數據寫入）。那么舊master中的數據就會被刷新掉，此時數據還是會丟失。

2.集群產生腦裂

首先我們需要理解集群的腦裂現象，這就好比一個人有兩個大腦，那么到底受誰來控制呢？在分布式集群中，分布式協作框架zookeeper很好的解決了這個問題，通過控制半數以上的機器來解決。

那么在redis中，集群腦裂產生數據丟失的現象是怎么樣的呢？

假設我們有一個redis集群，正常情況下client會向master發送請求，然后同步到salve，sentinel集群監控著集群，在集群發生故障時進行自動故障轉移。

此時，由于某種原因，比如網絡原因，集群出現了分區，master與slave節點之間斷開了聯系，sentinel監控到一段時間沒有聯系認為master故障，然后重新選舉，將slave切換為新的master。但是master可能并沒有發生故障，只是網絡產生分區，此時client任然在舊的master上寫數據，而新的master中沒有數據，如果不及時發現問題進行處理可能舊的master中堆積大量數據。在發現問題之后，舊的master降為slave同步新的master數據，那么之前的數據被刷新掉，大量數據丟失。

在了解了上面的兩種數據丟失場景后，我們如何保證數據可以不丟失呢？在分布式系統中，衡量一個系統的可用性，我們一般情況下會說4個9,5個9的系統達到了高可用（99.99%，99.999%，據說淘寶是5個9）。對于redis集群，我們不可能保證數據完全不丟失，只能做到使得盡量少的數據丟失。

二、如何保證盡量少的數據丟失？

在redis的配置文件中有兩個參數我們可以設置：

min-slaves-to-write默認情況下是0，min-slaves-max-lag默認情況下是10。

以上面配置為例，這兩個參數表示至少有1個salve的與master的同步復制延遲不能超過10s，一旦所有的slave復制和同步的延遲達到了10s，那么此時master就不會接受任何請求。

我們可以減小min-slaves-max-lag參數的值，這樣就可以避免在發生故障時大量的數據丟失，一旦發現延遲超過了該值就不會往master中寫入數據。

那么對于client，我們可以采取降級措施，將數據暫時寫入本地緩存和磁盤中，在一段時間后重新寫入master來保證數據不丟失；也可以將數據寫入kafka消息隊列，隔一段時間去消費kafka中的數據。

通過上面兩個參數的設置我們盡可能的減少數據的丟失，具體的值還需要在特定的環境下進行測試設置。

補充：redis cluster 會丟數據嗎？

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 在分區期間接收的寫入數量，降低數據丟失的損失。

以上為個人經驗，希望能給大家一個參考，也希望大家多多支持服務器之家。如有錯誤或未考慮完全的地方，望不吝賜教。

原文鏈接：https://blog.csdn.net/qq_37142346/article/details/89435458