Redis探索之旅(12)- Redis主從架構復制原理

在前一篇文章中,對Redis主從復制進行了較為詳細的說明,本文將參考redis官網上關于主從復制的說明進行簡單說明一下,這里對官網的英文描述進行簡單翻譯說明一下。首先說明下主從復制的特點,然后對主從復制的原理進行簡單描述,最后對主從復制需要注意的問題進行說明。

官網說明:http://redis.io/topics/replication

首先,我們看看主從復制的一些特點:

(1)采用異步復制;

(2)一個主redis可以含有多個從redis;

(3)每個從redis可以接收來自其他從redis服務器的連接;

(4)主從復制對于主redis服務器來說是非阻塞的,這意味著當從服務器在進行主從復制同步過程中,主redis仍然可以處理外界的訪問請求;

(5)主從復制對于從redis服務器來說也是非阻塞的,這意味著,即使從redis在進行主從復制過程中也可以接受外界的查詢請求,只不過這時候從redis返回的是以前老的數據,如果你不想這樣,那么在啟動redis時,可以在配置文件中進行設置,那么從redis在復制同步過程中來自外界的查詢請求都會返回錯誤給客戶端;(雖然說主從復制過程中對于從redis是非阻塞的,但是當從redis從主redis同步過來最新的數據后還需要將新數據加載到內存中,在加載到內存的過程中是阻塞的,在這段時間內的請求將會被阻塞,但是即使對于大數據集,加載到內存的時間也是比較多的);

(6)主從復制提高了redis服務的擴展性,避免單個redis服務器的讀寫訪問壓力過大的問題,同時也可以給為數據備份及冗余提供一種解決方案;

(7)為了編碼主redis服務器寫磁盤壓力帶來的開銷,可以配置讓主redis不在將數據持久化到磁盤,而是通過連接讓一個配置的從redis服務器及時的將相關數據持久化到磁盤,不過這樣會存在一個問題,就是主redis服務器一旦重啟,因為主redis服務器數據為空,這時候通過主從同步可能導致從redis服務器上的數據也被清空;

接下來我們看看redis大概主從同步是怎么實現的?

redis主從同步分為兩種情況,一種是全量同步(使用SYNC),一種是部分同步(使用PSYNC)。

那么兩者有什么不同呢?

全量同步:master服務器會開啟一個后臺進程用于將redis中的數據生成一個rdb文件,與此同時,服務器會緩存所有接收到的來自客戶端的寫命令(包含增、刪、改),當后臺保存進程處理完畢后,會將該rdb文件傳遞給slave服務器,而slave服務器會將rdb文件保存在磁盤并通過讀取該文件將數據加載到內存,在此之后master服務器會將在此期間緩存的命令通過redis傳輸協議發送給slave服務器,然后slave服務器將這些命令依次作用于自己本地的數據集上最終達到數據的一致性。

部分同步:從redis 2.8版本以前,并不支持部分同步,當主從服務器之間的連接斷掉之后,master服務器和slave服務器之間都是進行全量數據同步,但是從redis 2.8開始,即使主從連接中途斷掉,也不需要進行全量同步,因為從這個版本開始融入了部分同步的概念。部分同步的實現依賴于在master服務器內存中給每個slave服務器維護了一份同步日志和同步標識,每個slave服務器在跟master服務器進行同步時都會攜帶自己的同步標識和上次同步的最后位置。當主從連接斷掉之后,slave服務器隔斷時間(默認1s)主動嘗試和master服務器進行連接,如果從服務器攜帶的偏移量標識還在master服務器上的同步備份日志中,那么就從slave發送的偏移量開始繼續上次的同步操作,如果slave發送的偏移量已經不再master的同步備份日志中(可能由于主從之間斷掉的時間比較長或者在斷掉的短暫時間內master服務器接收到大量的寫操作),則必須進行一次全量更新。在部分同步過程中,master會將本地記錄的同步備份日志中記錄的指令依次發送給slave服務器從而達到數據一致。

最后,我們對需要主要的幾個問題進行說明。

(1)在上面的全量同步過程中,master會將數據保存在rdb文件中然后發送給slave服務器,但是如果master上的磁盤空間有效怎么辦呢?那么此時全部同步對于master來說將是一份十分有壓力的操作了。此時可以通過無盤復制來達到目的,由master直接開啟一個socket將rdb文件發送給slave服務器。(無盤復制一般應用在磁盤空間有限但是網絡狀態良好的情況下)

(2)主從復制結構,一般slave服務器不能進行寫操作,但是這不是死的,之所以這樣是為了更容易的保證主和各個從之間數據的一致性,如果slave服務器上數據進行了修改,那么要保證所有主從服務器都能一致,可能在結構上和處理邏輯上更為負責。不過你也可以通過配置文件讓從服務器支持寫操作。(不過所帶來的影響還得自己承擔哦。。。)

(3)主從服務器之間會定期進行通話,但是如果master上設置了密碼,那么如果不給slave設置密碼就會導致slave不能跟master進行任何操作,所以如果你的master服務器上有密碼,那么也給slave相應的設置一下密碼吧(通過設置配置文件中的masterauth);

(4)關于slave服務器上過期鍵的處理,由master服務器負責鍵的過期刪除處理,然后將相關刪除命令已數據同步的方式同步給slave服務器,slave服務器根據刪除命令刪除本地的key。

備注:關于本文如果有寫的不對的地方,還望指出,謝謝。

著作權歸作者所有。商業轉載請聯系作者獲得授權,非商業轉載請注明出處。互聯網+時代,時刻要保持學習,攜手千鋒PHP,Dream It Possible。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 229,565評論 6 539
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,115評論 3 423
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 177,577評論 0 382
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,514評論 1 316
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,234評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,621評論 1 326
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,641評論 3 444
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,822評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,380評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,128評論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,319評論 1 371
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,879評論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,548評論 3 348
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,970評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,229評論 1 291
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,048評論 3 397
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,285評論 2 376

推薦閱讀更多精彩內容