自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

Redis高可用原理,這下能看懂了吧!

存儲(chǔ) 存儲(chǔ)軟件 Redis
Redis 是被廣泛使用的基礎(chǔ)軟件之一,對(duì)于架構(gòu)師和運(yùn)維人員來說,了解 Redis 的高可用方案和背后的原理,是必備的基礎(chǔ)知識(shí)。

 Redis 是被廣泛使用的基礎(chǔ)軟件之一,對(duì)于架構(gòu)師和運(yùn)維人員來說,了解 Redis 的高可用方案和背后的原理,是必備的基礎(chǔ)知識(shí)。

本文作者深入分析了 Redis 高可用的方方面面,并且做了有效總結(jié),相信對(duì)廣大讀者可以起到很好的領(lǐng)路作用。

Redis 中為了實(shí)現(xiàn)高可用采用了如下兩個(gè)方式:

  • 主從復(fù)制數(shù)據(jù)。
  • 采用哨兵監(jiān)控?cái)?shù)據(jù)節(jié)點(diǎn)的運(yùn)行情況,一旦主節(jié)點(diǎn)出現(xiàn)問題由從節(jié)點(diǎn)頂上繼續(xù)進(jìn)行服務(wù)。

主從復(fù)制

Redis 中主從節(jié)點(diǎn)復(fù)制數(shù)據(jù)有全量復(fù)制和部分復(fù)制之分。

舊版本全量復(fù)制功能的實(shí)現(xiàn)

 

全量復(fù)制使用 Snyc 命令來實(shí)現(xiàn),其流程是:

  • 從服務(wù)器向主服務(wù)器發(fā)送 Sync 命令。
  • 主服務(wù)器在收到 Sync 命令之后,調(diào)用 Bgsave 命令生成***的 RDB 文件,將這個(gè)文件同步給從服務(wù)器,這樣從服務(wù)器載入這個(gè) RDB 文件之后,狀態(tài)就會(huì)和主服務(wù)器執(zhí)行 Bgsave 命令時(shí)候的一致。
  • 主服務(wù)器將保存在命令緩沖區(qū)中的寫命令同步給從服務(wù)器,從服務(wù)器執(zhí)行這些命令,這樣從服務(wù)器的狀態(tài)就跟主服務(wù)器當(dāng)前狀態(tài)一致了。

舊版本全量復(fù)制功能,其***的問題是從服務(wù)器斷線重連時(shí),即便在從服務(wù)器上已經(jīng)有一部分?jǐn)?shù)據(jù)了,也需要進(jìn)行全量復(fù)制,這樣做的效率很低,于是新版本的 Redis 在這部分做了改進(jìn)。

新版本全量復(fù)制功能的實(shí)現(xiàn)

新版本 Redis 使用 Psync 命令來代替 Sync 命令,該命令既可以實(shí)現(xiàn)完整全同步也可以實(shí)現(xiàn)部分同步。

復(fù)制偏移量

執(zhí)行復(fù)制的雙方,主從服務(wù)器,分別會(huì)維護(hù)一個(gè)復(fù)制偏移量:

主服務(wù)器每次向從服務(wù)器同步了 N 字節(jié)數(shù)據(jù)之后,將修改自己的復(fù)制偏移量 +N。

從服務(wù)器每次從主服務(wù)器同步了 N 字節(jié)數(shù)據(jù)之后,將修改自己的復(fù)制偏移量 +N。

復(fù)制積壓緩沖區(qū)

 

主服務(wù)器內(nèi)部維護(hù)了一個(gè)固定長(zhǎng)度的先進(jìn)先出隊(duì)列做為復(fù)制積壓緩沖區(qū),其默認(rèn)大小為 1MB。

在主服務(wù)器進(jìn)行命令傳播時(shí),不僅會(huì)將寫命令同步到從服務(wù)器,還會(huì)將寫命令寫入復(fù)制積壓緩沖區(qū)。

服務(wù)器運(yùn)行 ID

每個(gè) Redis 服務(wù)器,都有其運(yùn)行 ID,運(yùn)行 ID 由服務(wù)器在啟動(dòng)時(shí)自動(dòng)生成,主服務(wù)器會(huì)將自己的運(yùn)行 ID 發(fā)送給從服務(wù)器,而從服務(wù)器會(huì)將主服務(wù)器的運(yùn)行 ID 保存起來。

從服務(wù)器 Redis 斷線重連之后進(jìn)行同步時(shí),就是根據(jù)運(yùn)行 ID 來判斷同步的進(jìn)度:

  • 如果從服務(wù)器上面保存的主服務(wù)器運(yùn)行 ID 與當(dāng)前主服務(wù)器運(yùn)行 ID 一致,則認(rèn)為這一次斷線重連連接的是之前復(fù)制的主服務(wù)器,主服務(wù)器可以繼續(xù)嘗試部分同步操作。
  • 否則,如果前后兩次主服務(wù)器運(yùn)行 ID 不相同,則認(rèn)為是完成全同步流程。

Psync 命令流程

有了前面的準(zhǔn)備,下面開始分析 Psync 命令的流程:

  • 如果從服務(wù)器之前沒有復(fù)制過任何主服務(wù)器,或者之前執(zhí)行過 slaveof no one 命令,那么從服務(wù)器就會(huì)向主服務(wù)器發(fā)送 psync ? -1 命令,請(qǐng)求主服務(wù)器進(jìn)行數(shù)據(jù)的全量同步。
  • 否則,如果前面從服務(wù)器已經(jīng)同步過部分?jǐn)?shù)據(jù),那么從服務(wù)器向主服務(wù)器發(fā)送 psync 命令,其中 runid 是上一次主服務(wù)器的運(yùn)行 id,offset 是當(dāng)前從服務(wù)器的復(fù)制偏移量。

 

前面兩種情況主服務(wù)器收到 Psync 命令之后,會(huì)出現(xiàn)以下三種可能:

  • 主服務(wù)器返回 +fullresync 回復(fù),表示主服務(wù)器要求與從服務(wù)器進(jìn)行完整的數(shù)據(jù)全量同步操作。

其中,runid 是當(dāng)前主服務(wù)器運(yùn)行 id,而 offset 是當(dāng)前主服務(wù)器的復(fù)制偏移量。

  • 如果主服務(wù)器應(yīng)答 +continue,那么表示主服務(wù)器與從服務(wù)器進(jìn)行部分?jǐn)?shù)據(jù)同步操作,將從服務(wù)器缺失的數(shù)據(jù)同步過來即可。
  • 如果主服務(wù)器應(yīng)答 -err,那么表示主服務(wù)器版本低于 2.8,識(shí)別不了 Psync 命令,此時(shí)從服務(wù)器將向主服務(wù)器發(fā)送 Sync 命令,執(zhí)行完整的全量數(shù)據(jù)同步。

哨兵機(jī)制概述

Redis 使用哨兵機(jī)制來實(shí)現(xiàn)高可用的大概工作原理是:

  • Redis 使用一組哨兵(Sentinel)節(jié)點(diǎn)來監(jiān)控主從 Redis 服務(wù)的可用性。
  • 一旦發(fā)現(xiàn) Redis 主節(jié)點(diǎn)失效,將選舉出一個(gè)哨兵節(jié)點(diǎn)作為***(Leader)。
  • 哨兵***再從剩余的從 Redis 節(jié)點(diǎn)中選出一個(gè) Redis 節(jié)點(diǎn)作為新的主 Redis 節(jié)點(diǎn)對(duì)外服務(wù)。

以上將 Redis 節(jié)點(diǎn)分為兩類:

  • 哨兵節(jié)點(diǎn)(Sentinel):負(fù)責(zé)監(jiān)控節(jié)點(diǎn)的運(yùn)行情況。
  • 數(shù)據(jù)節(jié)點(diǎn):即正常服務(wù)客戶端請(qǐng)求的 Redis 節(jié)點(diǎn),有主從之分。

以上是大體的流程,這個(gè)流程需要解決以下幾個(gè)問題:

  • 如何對(duì) Redis 數(shù)據(jù)節(jié)點(diǎn)進(jìn)行監(jiān)控?
  • 如何確定一個(gè) Redis 數(shù)據(jù)節(jié)點(diǎn)失效?
  • 如何選擇出一個(gè)哨兵***節(jié)點(diǎn)?
  • 哨兵節(jié)點(diǎn)選擇新的主 Redis 節(jié)點(diǎn)的依據(jù)是什么?

以下來逐個(gè)回答這些問題。

三個(gè)監(jiān)控任務(wù)

哨兵節(jié)點(diǎn)通過三個(gè)定時(shí)監(jiān)控任務(wù)監(jiān)控 Redis 數(shù)據(jù)節(jié)點(diǎn)的服務(wù)可用性。

①info 命令

 

每隔 10 秒,每個(gè)哨兵節(jié)點(diǎn)都會(huì)向主、從 Redis 數(shù)據(jù)節(jié)點(diǎn)發(fā)送 info 命令,獲取新的拓?fù)浣Y(jié)構(gòu)信息。

Redis 拓?fù)浣Y(jié)構(gòu)信息包括了:

  • 本節(jié)點(diǎn)角色:主或從。
  • 主從節(jié)點(diǎn)的地址、端口信息。

這樣,哨兵節(jié)點(diǎn)就能從 info 命令中自動(dòng)獲取到從節(jié)點(diǎn)信息,因此那些后續(xù)才加入的從節(jié)點(diǎn)信息不需要顯式配置就能自動(dòng)感知。

②向 __sentinel__:hello 頻道同步信息

每隔 2 秒,每個(gè)哨兵節(jié)點(diǎn)將會(huì)向 Redis 數(shù)據(jù)節(jié)點(diǎn)的 __sentinel__:hello 頻道同步自身得到的主節(jié)點(diǎn)信息以及當(dāng)前哨兵節(jié)點(diǎn)的信息。

由于其他哨兵節(jié)點(diǎn)也訂閱了這個(gè)頻道,因此實(shí)際上這個(gè)操作可以交換哨兵節(jié)點(diǎn)之間關(guān)于主節(jié)點(diǎn)以及哨兵節(jié)點(diǎn)的信息。

 

這一操作實(shí)際上完成了兩件事情:

  • 發(fā)現(xiàn)新的哨兵節(jié)點(diǎn):如果有新的哨兵節(jié)點(diǎn)加入,此時(shí)保存下來這個(gè)新哨兵節(jié)點(diǎn)的信息,后續(xù)與該哨兵節(jié)點(diǎn)建立連接。
  • 交換主節(jié)點(diǎn)的狀態(tài)信息,作為后續(xù)客觀判斷主節(jié)點(diǎn)下線的依據(jù)。

③向數(shù)據(jù)節(jié)點(diǎn)做心跳探測(cè)

 

每隔 1 秒,每個(gè)哨兵節(jié)點(diǎn)向主、從數(shù)據(jù)節(jié)點(diǎn)以及其他 Sentinel 節(jié)點(diǎn)發(fā)送 Ping 命令做心跳探測(cè),這個(gè)心跳探測(cè)是后續(xù)主觀判斷數(shù)據(jù)節(jié)點(diǎn)下線的依據(jù)。

主觀下線和客觀下線

①主觀下線

上面三個(gè)監(jiān)控任務(wù)中的第三個(gè)探測(cè)心跳任務(wù),如果在配置的 down-after-milliseconds 之后沒有收到有效回復(fù),那么就認(rèn)為該數(shù)據(jù)節(jié)點(diǎn)“主觀下線(sdown)”。

 

為什么稱為“主觀下線”?因?yàn)樵谝粋€(gè)分布式系統(tǒng)中,有多個(gè)機(jī)器在一起聯(lián)動(dòng)工作,網(wǎng)絡(luò)可能出現(xiàn)各種狀況,僅憑一個(gè)節(jié)點(diǎn)的判斷還不足以認(rèn)為一個(gè)數(shù)據(jù)節(jié)點(diǎn)下線了,這就需要后面的“客觀下線”。

②客觀下線

 

當(dāng)一個(gè)哨兵節(jié)點(diǎn)認(rèn)為主節(jié)點(diǎn)主觀下線時(shí),該哨兵節(jié)點(diǎn)需要通過”sentinel is-master-down-by addr”命令向其他哨兵節(jié)點(diǎn)咨詢?cè)撝鞴?jié)點(diǎn)是否下線了,如果有超過半數(shù)的哨兵節(jié)點(diǎn)都回答了下線,此時(shí)認(rèn)為主節(jié)點(diǎn)“客觀下線”。

選舉哨兵***

當(dāng)主節(jié)點(diǎn)客觀下線時(shí),需要選舉出一個(gè)哨兵節(jié)點(diǎn)做為哨兵***,以完成后續(xù)選出新的主節(jié)點(diǎn)的工作。

這個(gè)選舉的大體思路是:

  • 每個(gè)哨兵節(jié)點(diǎn)通過向其他哨兵節(jié)點(diǎn)發(fā)送”sentinel is-master-down-by addr”命令來申請(qǐng)成為哨兵***。
  • 而每個(gè)哨兵節(jié)點(diǎn)在收到一個(gè)”sentinel is-master-down-by addr”命令時(shí),只允許給***個(gè)節(jié)點(diǎn)投票,其他節(jié)點(diǎn)的該命令都會(huì)被拒絕。
  • 如果一個(gè)哨兵節(jié)點(diǎn)收到了半數(shù)以上的同意票,則成為哨兵***。
  • 如果前面三步在一定時(shí)間內(nèi)都沒有選出一個(gè)哨兵***,將重新開始下一次選舉。

可以看到,這個(gè)選舉***的流程很像 Raft 中選舉 Leader 的流程。

選出新的主節(jié)點(diǎn)

 

在剩下的 Redis 從節(jié)點(diǎn)中,按照以下順序來選擇新的主節(jié)點(diǎn):

  • 過濾掉“不健康”的數(shù)據(jù)節(jié)點(diǎn):比如主觀下線、斷線的從節(jié)點(diǎn)、五秒內(nèi)沒有回復(fù)過哨兵節(jié)點(diǎn) Ping 命令的節(jié)點(diǎn)、與主節(jié)點(diǎn)失聯(lián)的從節(jié)點(diǎn)。
  • 選擇 Slave-Priority(從節(jié)點(diǎn)優(yōu)先級(jí))***的從節(jié)點(diǎn),如果存在則返回,不存在則繼續(xù)后面的流程。
  • 選擇復(fù)制偏移量***的從節(jié)點(diǎn),這意味著這個(gè)從節(jié)點(diǎn)上面的數(shù)據(jù)最完整,如果存在則返回,不存在則繼續(xù)后面的流程。
  • 到了這里,所有剩余從節(jié)點(diǎn)的狀態(tài)都是一樣的,選擇 runid 最小的從節(jié)點(diǎn)。

提升新的主節(jié)點(diǎn)

 

選擇了新的主節(jié)點(diǎn)之后,還需要***的流程讓該節(jié)點(diǎn)成為新的主節(jié)點(diǎn):

  • 哨兵***向上一步選出的從節(jié)點(diǎn)發(fā)出“slaveof no one”命令,讓該節(jié)點(diǎn)成為主節(jié)點(diǎn)。
  • 哨兵***向剩余的從節(jié)點(diǎn)發(fā)送命令,讓它們成為新主節(jié)點(diǎn)的從節(jié)點(diǎn)。
  • 哨兵節(jié)點(diǎn)集合會(huì)將原來的主節(jié)點(diǎn)更新為從節(jié)點(diǎn),當(dāng)其恢復(fù)之后命令它去復(fù)制新的主節(jié)點(diǎn)的數(shù)據(jù)。

作者:codedump

簡(jiǎn)介:codedump.info 博主,多年從事互聯(lián)網(wǎng)服務(wù)器后臺(tái)開發(fā)工作??稍L問作者博客 https://www.codedump.info 更多文章。

 

責(zé)任編輯:武曉燕 來源: 高可用架構(gòu)
相關(guān)推薦

2013-09-22 10:34:08

碼農(nóng)機(jī)器學(xué)習(xí)算法

2024-11-01 05:10:00

2019-03-26 11:15:34

AI機(jī)器學(xué)習(xí)人工智能

2017-02-22 15:04:52

2020-02-28 08:00:35

單點(diǎn)登錄系統(tǒng)

2023-01-26 00:22:01

分布式架構(gòu)大文件

2018-12-24 08:46:52

Kubernetes對(duì)象模型

2019-12-27 09:47:05

大數(shù)據(jù)TomcatWeb

2022-07-04 08:31:42

GitOpsGit基礎(chǔ)設(shè)施

2020-02-15 17:16:05

Kubernetes容器

2019-11-18 10:38:03

線程池Java框架

2020-01-21 10:16:15

Kubernetes教程容器

2019-10-08 10:10:52

中臺(tái) IT后臺(tái)

2020-12-01 09:03:22

分庫分表MySQL

2019-10-10 11:10:04

SpringBoot異步編程

2019-09-05 14:21:22

JavaNIOBIO

2022-06-21 07:51:06

Redis高可用哨兵進(jìn)程

2018-11-19 08:34:22

Hadoop架構(gòu)HDFS

2018-11-21 09:40:57

熔斷實(shí)踐AOP

2018-11-21 15:40:08

HTTP協(xié)議前端
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)