跟隨槓精的視角一起來了解Redis的主從複製

detectiveHLH發表於2020-12-01

不想彈好吉他的擼鐵狗,都不是好的程式猿

雖然說單機的Redis效能很好,也有完備的持久化機制,那如果你的業務體量真的很大,超過了單機能夠承載的上限了怎麼辦?不做任何處理的話Redis掛了怎麼辦?帶著這個問題開始我們今天的主題-Redis高可用,由於篇幅原因,本章就只聊聊主從複製。

為啥要先從主從複製開始聊,是因為主從複製可以說是整個Redis高可用實現的基石,你可以先有這麼一個概念,至於具體為什麼是基石,這個後面聊到Sentinel和Redis叢集的時候會說到。

首先我們需要知道,對於我們開發人員來說,為什麼需要主從架構?一個Redis例項難道不行嗎?

其實除了開篇提到的負載超過了Redis單機能夠處理的上限,還有一種情況Redis也無法保證自身的高可用性。那就是即便Redis能夠扛住所有流量,但是如果這個Redis程式所在的機器掛了呢?請求會直接調轉槍口,大量的流量會瞬間把你的DB打掛,然後你就可以背個P0,打包回家了。

而且,假設你對Redis的需求真的超過了單機的容量,你怎麼辦?搞多臺獨立的Redis例項嗎?那如果使用者快取的資料這一次存在了例項一,下一次如果使用者又訪問到了例項二,難道又要去走一遍DB嗎?除非你能夠維護好使用者和Redis例項的對應關係(但是通常這樣的邏輯比較複雜),否則部署多個Redis例項也就失去了它的意義,沒有辦法做到橫向擴充套件了。

那換成主從架構就能解決這個問題嗎?

我們可以從一個圖來直觀的瞭解一下。

Redis主從複製
Redis主從複製

在主從同步中,我們將節點的角色劃分為masterslave,形成一主多從。slave對外提供讀操作,而master負責寫操作,形成一個讀寫分離的架構,這樣一來就能夠承載更多的業務請求。

在多數的業務場景下,對於Redis的讀操作都要多於寫操作,所以當讀請求量特別大的時候,我們可以通過增加slave節點來使Redis扛住更多的流量。

你這不行啊老弟,你往master寫資料,那我要是連線到slave上去了,不就拿不到之前的資料了?

我這個小標題的不是寫了嗎?主從複製,slave會按照某種策略從master同步資料。Redis中我們可以通過slaveof命令讓一個Redis例項去複製(replicate)另外一臺Redis的狀態。被複制的Redis例項就是master節點,而執行slaveof命令的機器就是slave節點。

Redis的主從複製分為兩個步驟,分別是同步命令傳播

同步操作用於將Master節點記憶體狀態複製給Slave節點,而命令傳播則是在同步時,客戶端又執行了一些操作改變了伺服器的狀態,此時master節點的狀態與同步操作執行的時候不一致了,所以需要命令傳播來使master和slave狀態重新一致。

同步的大致的流程如下:

  • slave節點向master節點傳送sync命令
  • master收到sync命令之後會執行bgsave命令,Redis會fork出一個子程式在後臺生成RDB檔案,同時將同步過程中的寫命令記錄到緩衝區中
  • 檔案生成後,master會把RDB檔案傳送給slave,從伺服器接收到RDB檔案會將其載入記憶體
  • 然後master將記錄在緩衝區的所有寫命令傳送給slave,slave對這些命令進行重放,將其資料庫的狀態更新至和master一致

為了讓大家更加清晰的認識到這個過程,我們通過圖再來了解一下。

Redis主從複製
Redis主從複製

??,那如果同步完了之後slave又掛了咋辦?slave重啟之後很可能就又跟maste不一致了?

的確是這樣,這就涉及到一個名詞叫斷點續傳了。上面討論的是slave第一次連線到master,會執行全量複製,而針對上面這種情況,Redis新老版本處理方式不一樣。

Redis2.8之前,當主從完成了同步之後,slave如果斷線重連,向master傳送sync命令,master會將全量的資料再次同給slave。

但是我們會發現一個問題,就是大部分資料都是有序的,再次全量同步顯得沒有必要。而在 Redis2.8之後,為了解決這個問題,便使用了psync命令來代替sync

簡單來說psync命令就是將slave斷線期間master接收到的寫命令全部傳送給slave,slave重放之後狀態便與master一致了。

呵呵,就這?那你知道psync具體怎麼實現的嗎?還是說就只會用用?

psync的實現依賴於主從雙方共同維護的offset偏移量。

每次master向slave進行命令傳播,傳播了多少個位元組的資料,就將自己的offset加上傳播的位元組數。而slave每次收到多少位元組的資料,也會同樣的更新自己的offset。

基於offset,只需要簡單的比對就知道當前主從的狀態是否是一致的了,然後基於offset,將對應偏移量所對應的指令傳播給slave重放即可。所以即使同步的時候slave掛掉了,基於offset,也能達到斷點續傳的效果。

不是吧不是吧,那master也掛了呢?你slave重新啟動之後master的資料也更新了,按照你的說法,這兩永遠不可能達到資料一致了

這個問題Redis的確也有想到,實際上除了offset之外,slave斷線重連之後還會帶上上一個master的例項的runid,每個服務例項都有自己的唯一的runid,只要Redis服務重啟,其runid就會發生改變。

master收到這個runid之後會判斷是否與自己當前的runid一致,如果一致說明斷線之前還是與自己建立的連線,而如果不一致就說明slave斷線期間,master也發生了當機,此時就需要將資料全量同步給slave了。

redis-runid
redis-runid

就算你能解決這個問題,但是你就維護了一個偏移量,偏移量對應的命令從哪兒來?天上掉下來嗎?我哪兒知道這些命令是啥?

的確,我們需要通過這個offset去拿到真正需要的資料—也就是指令,而Redis是通過複製積壓緩衝區來實現的。

名字高大上,實際上就是一佇列。就跟什麼遞迴、輪詢、透傳一樣,聽著高大上,實際上簡單的一匹。言歸正傳,複製積壓緩衝區的預設大小為1M,Redis在進行命令傳播時,除了將寫命令傳送給slave,還會將命令寫到複製積壓緩衝區內,並和當前的offset關聯起來。這樣一來就能夠通過offset獲取到對應的指令了。

redis-backlog
redis-backlog

但是由於緩衝區的大小有限,如果slave的斷線時間太久,複製積壓緩衝區內早些時候的指令就已經被新的指令覆蓋掉了,此處可以理解為一個佇列,早些時候入隊的元素已經被出隊了。

由於沒有相對應的offset了,也就無法獲取指令資料,此時Redis就會進行全量同步。當然,如果offset還存在於複製積壓緩衝區中,則按照對應的offset進行部分同步

基於以上的全量、增量的主從複製,能夠在master出現故障的情況下,進行主從的切換,保證服務的正常執行。除此之外還能解決異常情況下資料丟失的問題。基於讀寫分離的策略還能夠提高整個Redis服務的併發量。

可別吹了,你說的這個什麼主從複製就沒啥缺點嗎?

其實是有的,例如剛剛提到的主從的切換,如果不用現成的HA框架,這個過程需要程式設計師自己手動的完成,同時通知服務呼叫方Redis的IP發生了變化,這個過程可以說是十分的複雜,甚至還可能涉及到程式碼配置的改動。而且之前的slave複製的可都是掛掉的master,還得去slave上更改其複製的主庫,就更加複雜了。

除此之外,雖然實現了讀寫分離,但是由於是一主多從的架構,叢集的讀請求可以擴充套件,但是寫請求的併發是有上限的,那就是master能夠扛住的上限,這個沒有辦法擴充套件。

好了,本期的分享就到此結束了,我們下期再見。

如果你覺得這篇文章對你有幫助,還麻煩點個贊關個注分個享留個言

也可以微信搜尋公眾號【SH的全棧筆記】,關注公眾號提前閱讀其他的文章

往期文章

相關文章