1 數(shù)據(jù)丟失的兩個場景

主備切換的過程，可能會導(dǎo)致數(shù)據(jù)丟失

1.1 異步復(fù)制

由于 master => slave的復(fù)制是異步的，所以可能有部分?jǐn)?shù)據(jù)還沒復(fù)制到slave，master就宕機(jī)，于是這些數(shù)據(jù)就丟失了

1.2 腦裂導(dǎo)致

腦裂，也就是說，某個master所在節(jié)點突然脫離正常的網(wǎng)絡(luò)，無法和其他slave機(jī)器連接，但實際上master還運行著

此時哨兵可能就會認(rèn)為master宕機(jī)了，然后開啟選舉，將其他slave切換成了master

這個時候，集群里就會有兩個master，也就是所謂的腦裂

此時雖然某個slave被切換成了master，但是可能client還沒來得及切換到新的master，還繼續(xù)寫向舊master的數(shù)據(jù)可能也丟失了

因此舊master再次恢復(fù)時，會被作為一個slave掛到新的master上去，自己的數(shù)據(jù)會被清空，重新從新的master復(fù)制數(shù)據(jù)

2 數(shù)據(jù)丟失的解決方案

如下配置可以減少異步復(fù)制和腦裂導(dǎo)致的數(shù)據(jù)丟失

min-slaves-to-write 1

min-slaves-max-lag 10

配置要求至少有1個slave，數(shù)據(jù)復(fù)制和同步的延遲不能超過10秒

一旦所有的slave，數(shù)據(jù)復(fù)制和同步的延遲都超過了10秒鐘，master就不再接收任何請求!

2.1 異步復(fù)制數(shù)據(jù)丟失解決方案

min-slaves-max-lag 配置

即可確保，一旦slave復(fù)制數(shù)據(jù)和ack延時過長，就認(rèn)為可能master宕機(jī)后損失的數(shù)據(jù)太多了，那么就拒絕寫請求

這樣就可把master宕機(jī)時由于部分?jǐn)?shù)據(jù)未同步到slave導(dǎo)致的數(shù)據(jù)丟失降低在可控范圍

2.2 腦裂數(shù)據(jù)丟失解決方案

若一個master出現(xiàn)了腦裂，跟其他slave失去連接，那么開始的兩個配置可以確保

若不能繼續(xù)給指定數(shù)量的slave發(fā)送數(shù)據(jù)，而且slave超過10秒沒有給自己ack消息，那么就直接拒絕客戶端的寫請求

這樣腦裂后的舊master就不會接受client的新數(shù)據(jù)，也就避免了數(shù)據(jù)丟失

上面的配置就確保了，如果跟任何一個slave丟了連接，在10秒后發(fā)現(xiàn)沒有slave給自己ack，那么就拒絕新的寫請求

因此在腦裂場景下，最多就丟失10秒的數(shù)據(jù)

參考

《Java工程師面試突擊第1季-中華石杉老師》

歡迎關(guān)注全是硬核干貨的公眾號:JavaEdge

總結(jié)

以上是生活随笔為你收集整理的redis 哨兵 异步_突破Java面试(23-8) - Redis哨兵主备切换的数据丢失问题-阿里云开发者社区...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。