當(dāng)前位置:首頁 > IT技術(shù) > 其他 > 正文

(進階篇)Redis6.2.0 集群 主從復(fù)制_故障解決_03
2022-09-06 22:54:42


文章目錄

一、 主從數(shù)據(jù)一致性
1. 主多從少

主從網(wǎng)絡(luò)延遲時,主多從少情況下,進行部分重同步。
場景簡述:主多從少就是在網(wǎng)絡(luò)延遲的情況下,從服務(wù)器尚未把主服務(wù)器的數(shù)據(jù)全部復(fù)制過來。
解決方案:
第一種:這時,我們可以等延遲結(jié)束之后,讓從服務(wù)器進行部分重同步,就是我們說增量復(fù)制。
第二種:如果比較著急,向讓他立刻執(zhí)行重同步,需要任務(wù)干預(yù)。在從節(jié)點輸入

psync 主節(jié)點master的run_id 追加需要復(fù)制的起始偏移量offset

就可以實現(xiàn)部分重同步
第三種:人為斷開讓從節(jié)點和主節(jié)點重新建立連接,也會觸發(fā)部分重同步。

2. 主少從多

主少從多情況下,進行全量復(fù)制。
場景簡述(主少從多):這種情況是從服務(wù)器開啟了寫的操作導(dǎo)致的,也就是我們的從服務(wù)器是讀寫模式,當(dāng)從從服務(wù)器寫入,就會導(dǎo)致主從不一致。
解決方案:
把從服務(wù)器數(shù)據(jù)清空,讓從服務(wù)器和主服務(wù)器重新建立連接,進行去哪量數(shù)據(jù)復(fù)制即可。

3. 知識點補充

在redis2.8版本之前,如果從節(jié)點和主節(jié)點斷開重新連接,從節(jié)點就會全量復(fù)制,這無疑是一個降低性能的問題。
為了解決這個問題,redis在2.8版本之后,添加了一個特性;我們主從斷開重連的時候,可以進行一個邏輯判斷處理,來判斷從節(jié)點進行全量復(fù)制還是增量復(fù)制?
其實就是我們的主服務(wù)器在內(nèi)存中為每一個從服務(wù)器都維護了一個同步日志和同步標識,這三個同步日志就是backlog ,這個同步標識就是offset,每個從服務(wù)器在跟主服務(wù)器進行同步的時候,會攜帶同步標識和上次同步的位置,這樣就會判斷出這個復(fù)制,要做全量復(fù)制還是增量復(fù)制。

二、 數(shù)據(jù)延遲
2.1. 數(shù)據(jù)延遲因素

數(shù)據(jù)延遲,根據(jù)那些配置或者屬性決定的。在info replication返回的信息中有一個偏移量,其實,就是根據(jù)這個偏移量來決定當(dāng)前數(shù)據(jù)的一個健康狀態(tài),數(shù)據(jù)是否有延遲,我們的主節(jié)點在寫入命令的時候,比如:我寫入3000字節(jié)的一個偏移量,此時,我們的從節(jié)點只復(fù)制了1000,他們的差值比較大的時候,就說明數(shù)據(jù)延遲就很高了。

2.2. 解決方案

1.編寫外部程序監(jiān)聽主從節(jié)點的復(fù)制偏移量,延遲較大時發(fā)出報警或者通知客戶端,切換到主節(jié)點或者其他節(jié)點。
2設(shè)置從節(jié)點???slave-serve-stale-data??為no 除INFO SLAVEOF命令之外的任何請求都會返回一個錯誤“SYNC with master in progress”

三、 臟數(shù)據(jù)
3.1. 臟數(shù)據(jù)產(chǎn)生的場景
  • 惰性:現(xiàn)在有一個key已經(jīng)過期了,現(xiàn)在沒有人活著客戶端訪問,就不會刪除這個過期的key;在訪問的時候在判斷這個key是否過期,過期了就會刪除,導(dǎo)致一個過期的key如果不被訪問就會永遠存在內(nèi)存中。
  • 定時:解決惰性缺點,內(nèi)部有一個定時任務(wù),隔一段時間就會判斷一批key是否過期,過期了就刪除掉。
  • 主動刪除:當(dāng)前數(shù)據(jù)存儲超過了redia的存儲上限,然后,觸發(fā)主動刪除,正是因為rerdis刪除機智的原因?qū)е掠信K數(shù)據(jù)的產(chǎn)生。
    從節(jié)點可寫導(dǎo)致的,從節(jié)點一般都是只讀模式,如果你開啟了讀寫模式,這個數(shù)據(jù)從從節(jié)點誤寫入,可能導(dǎo)致產(chǎn)生臟數(shù)據(jù)。
3.2. 解決方案
  • 忽略:比如:12306查詢票,雙11查詢庫存,當(dāng)你去查詢這些信息的時候,我并沒有去做一個寫操作,這樣業(yè)務(wù)場景允許你出現(xiàn)一定的的錯誤,有一定的容錯。我么可以選擇忽略。
  • 強制讀主:當(dāng)我們買一張車票,下單呢?秒殺搶購這個商品,這個時候數(shù)據(jù)一定要是準確的,我們可以采用強制讀主的方式,從節(jié)點間接變?yōu)榱藗浞莘?wù)器(某個業(yè)務(wù))
  • 從節(jié)點只讀:規(guī)避從節(jié)點寫入臟數(shù)據(jù)
    目前redis6.x之后,讀取數(shù)據(jù)之前檢查鍵過期時間來決定是否返回數(shù)據(jù)
四、 數(shù)據(jù)安全性
4.1. 場景

關(guān)閉主節(jié)點持久化會提升性能,同時會帶來復(fù)制的安全性問題。

(進階篇)Redis6.2.0 集群 主從復(fù)制_故障解決_03_解決方案

4.2. 解決方案

主節(jié)點不自動重啟,不是用shell腳本手段監(jiān)控主節(jié)點自動觸發(fā)重啟

五、 規(guī)避全量復(fù)制
5.1. 低峰時段

第一次全量復(fù)制解決方案:低峰時段掛載slave節(jié)點,比如:晚上12點

5.2. 主節(jié)點變更

選舉slave為主節(jié)點

待補充

5.3. 增大復(fù)制緩沖區(qū)
六、 規(guī)避復(fù)制風(fēng)暴
5.1. 單主節(jié)點

單主節(jié)點復(fù)制風(fēng)暴:主節(jié)點重啟,從節(jié)點全量復(fù)制
解決方案:
選舉slave為主節(jié)點、樹狀復(fù)制結(jié)構(gòu)

5.2. 單機多主

單機多主復(fù)制風(fēng)暴:一臺機器,多個主節(jié)點(樹狀復(fù)制架構(gòu))
解決方案:把主節(jié)點分散在多臺機器上


本文摘自 :https://blog.51cto.com/g

開通會員,享受整站包年服務(wù)立即開通 >