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

異步復(fù)制同步丟失

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

1.異步復(fù)制丟失

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

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

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

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

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

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

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

此時(shí)，由于某種原因，比如網(wǎng)絡(luò)原因，集群出現(xiàn)了分區(qū)，master與slave節(jié)點(diǎn)之間斷開了聯(lián)系，sentinel監(jiān)控到一段時(shí)間沒有聯(lián)系認(rèn)為master故障，然后重新選舉，將slave切換為新的master。但是master可能并沒有發(fā)生故障，只是網(wǎng)絡(luò)產(chǎn)生分區(qū)，此時(shí)client任然在舊的master上寫數(shù)據(jù)，而新的master中沒有數(shù)據(jù)，如果不及時(shí)發(fā)現(xiàn)問題進(jì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)中，衡量一個(gè)系統(tǒng)的可用性，我們一般情況下會(huì)說4個(gè)9,5個(gè)9的系統(tǒng)達(dá)到了高可用（99.99%，99.999%，據(jù)說淘寶是5個(gè)9）。對于redis集群，我們不可能保證數(shù)據(jù)完全不丟失，只能做到使得盡量少的數(shù)據(jù)丟失。

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

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

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

min-slaves-to-write默認(rèn)情況下是0，min-slaves-max-lag默認(rèn)情況下是10。

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

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

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

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

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

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

場景1：異步復(fù)制

client 寫入 master B

master B 回復(fù) OK

master B 同步至 slave B1 B2 B3

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

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

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

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

因?yàn)榧词故褂昧诉@種同步復(fù)制方式，也存在特殊情況：一個(gè)沒有完成同步的 slave 被選舉為了 master。

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

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

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

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

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

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

這個(gè)時(shí)間量是非常重要的，稱為節(jié)點(diǎn)過期時(shí)間。

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

小結(jié)

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

異步復(fù)制

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

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

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

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

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

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

最新評論