一、數(shù)據(jù)丟失的情況

異步復制同步丟失

集群產(chǎn)生腦裂數(shù)據(jù)丟失

1.異步復制丟失

對于Redis主節(jié)點與從節(jié)點之間的數(shù)據(jù)復制，是異步復制的，當客戶端發(fā)送寫請求給master節(jié)點的時候，客戶端會返回OK，然后同步到各個slave節(jié)點中。

如果此時master還沒來得及同步給slave節(jié)點時發(fā)生宕機，那么master內(nèi)存中的數(shù)據(jù)會丟失；

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

2.集群產(chǎn)生腦裂

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

那么在Redis中，集群腦裂產(chǎn)生數(shù)據(jù)丟失的現(xiàn)象是怎么樣的呢？

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

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

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

二、如何保證盡量少的數(shù)據(jù)丟失？

在redis的配置文件中有兩個參數(shù)我們可以設(shè)置：

min-slaves-to-write 1
min-slaves-max-lag 10

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

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

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

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

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

補充：Redis Cluster 會丟數(shù)據(jù)嗎？

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

場景1：異步復制

client 寫入 master B

master B 回復 OK

master B 同步至 slave B1 B2 B3

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

wait 命令可以增強這種場景的數(shù)據(jù)安全性。

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

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

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

場景2：網(wǎng)絡(luò)分區(qū)

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

發(fā)生網(wǎng)絡(luò)分區(qū)之后，形成了2個區(qū)，A, C, A1, B1, C1 和 B Z1。

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

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

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

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

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

小結(jié)

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

異步復制

在 master 寫成功，但 slave 同步完成之前，master 宕機了，slave 變?yōu)?master，數(shù)據(jù)丟失。

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

網(wǎng)絡(luò)分區(qū)

分區(qū)后一個 master 繼續(xù)接收寫請求，分區(qū)恢復后這個 master 可能會變?yōu)?slave，那么之前寫入的數(shù)據(jù)就丟了。

可以設(shè)置節(jié)點過期時間，減少 master 在分區(qū)期間接收的寫入數(shù)量，降低數(shù)據(jù)丟失的損失。

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。如有錯誤或未考慮完全的地方，望不吝賜教。

最新評論