Redis 有多種集群搭建方式，比如，主從模式、哨兵模式、Cluster 模式。

一、主從模式

Redis 主從模式還解決了單點(diǎn)的問題。Redis 主庫(kù)在進(jìn)行修改操作的時(shí)候，會(huì)把相應(yīng)的寫入命令近乎實(shí)時(shí)地同步給從庫(kù)，從庫(kù)回放這些命令，就可以保證自己的數(shù)據(jù)與主庫(kù)保持一致。那么，當(dāng)主庫(kù)發(fā)生宕機(jī)的時(shí)候，我們就可以將一個(gè)從庫(kù)升級(jí)為主庫(kù)繼續(xù)提供服務(wù)；當(dāng)一個(gè)從庫(kù)宕機(jī)的時(shí)候，主庫(kù)依舊可以處理寫請(qǐng)求，其他從庫(kù)依舊可以支持讀請(qǐng)求，所以并不會(huì)影響整個(gè) Redis 服務(wù)的讀寫。所以說，Redis 主從模式解決了 Redis 單點(diǎn)的問題。

1.主從復(fù)制——全量復(fù)制

2.主從復(fù)制——增量復(fù)制

主從復(fù)制的增量復(fù)制底層實(shí)現(xiàn)原理如下：

主節(jié)點(diǎn)的命令傳播： 當(dāng)主節(jié)點(diǎn)接收到客戶端的寫入命令（如SET、DEL等）時(shí)，會(huì)將這些命令先記錄在自己的AOF文件和內(nèi)存中，然后將這些命令逐個(gè)發(fā)送給所有連接的從節(jié)點(diǎn)。

命令傳輸?shù)綇墓?jié)點(diǎn)： 主節(jié)點(diǎn)通過網(wǎng)絡(luò)將寫入命令發(fā)送給從節(jié)點(diǎn)，從節(jié)點(diǎn)收到命令后先保存在自己的緩沖區(qū)中。

從節(jié)點(diǎn)的執(zhí)行： 從節(jié)點(diǎn)在空閑時(shí)，會(huì)從緩沖區(qū)中取出保存的命令，并按照主節(jié)點(diǎn)發(fā)送的順序逐個(gè)執(zhí)行這些命令。這樣，從節(jié)點(diǎn)的數(shù)據(jù)狀態(tài)會(huì)逐步與主節(jié)點(diǎn)保持一致。

初始復(fù)制和部分復(fù)制： 當(dāng)從節(jié)點(diǎn)剛剛與主節(jié)點(diǎn)建立連接時(shí)，會(huì)進(jìn)行初始復(fù)制，主節(jié)點(diǎn)會(huì)將自己的整個(gè)數(shù)據(jù)集發(fā)送給從節(jié)點(diǎn)。在初始復(fù)制完成后，從節(jié)點(diǎn)會(huì)繼續(xù)接收主節(jié)點(diǎn)的增量命令，進(jìn)行部分復(fù)制。

心跳檢測(cè)： 主節(jié)點(diǎn)會(huì)周期性地向從節(jié)點(diǎn)發(fā)送心跳消息，以檢測(cè)從節(jié)點(diǎn)的狀態(tài)。如果從節(jié)點(diǎn)在一定時(shí)間內(nèi)沒有回應(yīng)心跳消息，主節(jié)點(diǎn)會(huì)認(rèn)為從節(jié)點(diǎn)下線，并將其標(biāo)記為斷線狀態(tài)。

斷線重連： 當(dāng)從節(jié)點(diǎn)重新連接主節(jié)點(diǎn)時(shí)，主節(jié)點(diǎn)會(huì)根據(jù)從節(jié)點(diǎn)斷線前的復(fù)制偏移量，發(fā)送增量命令給從節(jié)點(diǎn)，以確保數(shù)據(jù)的連續(xù)性。

通過增量復(fù)制，主節(jié)點(diǎn)只需要傳輸寫入命令而不是整個(gè)數(shù)據(jù)集，大大減少了復(fù)制過程中的網(wǎng)絡(luò)傳輸開銷。從節(jié)點(diǎn)通過執(zhí)行主節(jié)點(diǎn)的寫入命令來更新自己的數(shù)據(jù)，實(shí)現(xiàn)了數(shù)據(jù)的同步和一致性。主從復(fù)制的增量復(fù)制是一種異步復(fù)制方式，所以主節(jié)點(diǎn)和從節(jié)點(diǎn)之間可能會(huì)存在一定的數(shù)據(jù)延遲，但它提供了高可用性和橫向擴(kuò)展的能力。

二、哨兵模式

一個(gè) Sentinel 服務(wù)進(jìn)程其實(shí)本身就是 Redis 實(shí)例，只不過這個(gè) Redis 服務(wù)實(shí)例是以 Sentinel 模式運(yùn)行的，它不對(duì)外提供讀寫鍵值對(duì)的服務(wù)，而是監(jiān)控其他 Redis 服務(wù)實(shí)例是否運(yùn)行正常，有點(diǎn)類似現(xiàn)實(shí)生活中監(jiān)工的感覺。

為了防止 Sentinel 本身出現(xiàn)單點(diǎn)問題，一般會(huì)將多個(gè) Sentinel 實(shí)例組成一個(gè) Sentinel 集群。Sentinel 核心功能是監(jiān)控線上 Redis 實(shí)例的狀態(tài)，當(dāng)發(fā)現(xiàn)某個(gè)主庫(kù)故障的時(shí)候，Sentinel 會(huì)自動(dòng)將故障的主庫(kù)下線，然后從剩余的從庫(kù)中選出一個(gè)合適的從庫(kù)，提升為新一任主庫(kù)，繼續(xù)對(duì)外提供服務(wù)。

Sentinel 有選舉的操作，所以一般推薦 Sentinel 集群的實(shí)例個(gè)數(shù)為奇數(shù)。
一個(gè) Sentinel 集群可以監(jiān)控多個(gè) Redis 主從集群。

1.實(shí)時(shí)監(jiān)控與故障轉(zhuǎn)移

Redis Sentinel實(shí)現(xiàn)實(shí)時(shí)監(jiān)控與故障轉(zhuǎn)移的底層原理如下：

• 1. 實(shí)時(shí)監(jiān)控：

  • 定期檢查：每個(gè)Redis Sentinel節(jié)點(diǎn)定期向被監(jiān)控的Redis主從節(jié)點(diǎn)發(fā)送PING命令，以檢查節(jié)點(diǎn)是否在線。同時(shí)，Sentinel還會(huì)使用INFO命令獲取節(jié)點(diǎn)的運(yùn)行狀態(tài)信息，包括主節(jié)點(diǎn)的復(fù)制偏移量、從節(jié)點(diǎn)復(fù)制狀態(tài)等。
  • 主觀下線：如果一個(gè)Sentinel節(jié)點(diǎn)在多次檢查中無法連接到主節(jié)點(diǎn)或從節(jié)點(diǎn)，它會(huì)將該節(jié)點(diǎn)標(biāo)記為“主觀下線”。這表示該Sentinel認(rèn)為節(jié)點(diǎn)可能出現(xiàn)了故障，但并不是確定性的。
  • 共識(shí)達(dá)成：Sentinel集群中的多個(gè)Sentinel會(huì)進(jìn)行共識(shí)達(dá)成，即判斷節(jié)點(diǎn)是否真正宕機(jī)。當(dāng)超過半數(shù)Sentinel認(rèn)為某個(gè)節(jié)點(diǎn)處于主觀下線狀態(tài)時(shí)，該節(jié)點(diǎn)會(huì)被標(biāo)記為“客觀下線”。

• 2. 故障轉(zhuǎn)移：

  • 客觀下線：一旦一個(gè)主節(jié)點(diǎn)被標(biāo)記為“客觀下線”，說明多數(shù)Sentinel都認(rèn)為該主節(jié)點(diǎn)處于故障狀態(tài)，故障轉(zhuǎn)移過程會(huì)開始。
  • 領(lǐng)導(dǎo)者選舉：在Sentinel集群中，會(huì)通過選舉機(jī)制選出一個(gè)Sentinel領(lǐng)導(dǎo)者。領(lǐng)導(dǎo)者負(fù)責(zé)協(xié)調(diào)整個(gè)Sentinel集群的監(jiān)控工作和故障轉(zhuǎn)移過程。
  • 選舉新的主節(jié)點(diǎn)：當(dāng)主節(jié)點(diǎn)被標(biāo)記為“客觀下線”時(shí)，Sentinel集群會(huì)重新選舉一個(gè)從節(jié)點(diǎn)作為新的主節(jié)點(diǎn)。這個(gè)過程是通過選舉機(jī)制和投票來實(shí)現(xiàn)的，最終選出一個(gè)從節(jié)點(diǎn)作為新的主節(jié)點(diǎn)。
  • 切換從節(jié)點(diǎn)：一旦新的主節(jié)點(diǎn)選出，其他從節(jié)點(diǎn)會(huì)切換到新的主節(jié)點(diǎn)上，使得整個(gè)Redis集群恢復(fù)到正常的主從復(fù)制狀態(tài)。

通過實(shí)時(shí)監(jiān)控和故障轉(zhuǎn)移，Redis Sentinel實(shí)現(xiàn)了高可用性，即使主節(jié)點(diǎn)出現(xiàn)故障，也能夠快速選舉新的主節(jié)點(diǎn)并恢復(fù)服務(wù)，保證了Redis集群的可用性和穩(wěn)定性。這種機(jī)制允許Redis Sentinel對(duì)節(jié)點(diǎn)的狀態(tài)進(jìn)行實(shí)時(shí)監(jiān)控，并自動(dòng)進(jìn)行故障轉(zhuǎn)移，無需人工干預(yù)，提高了系統(tǒng)的自動(dòng)化和可靠性。

2.Sentinel選舉領(lǐng)導(dǎo)者

Redis Sentinel中領(lǐng)導(dǎo)者的選舉是通過Raft算法實(shí)現(xiàn)的。Raft是一種一致性算法，用于在分布式系統(tǒng)中選舉領(lǐng)導(dǎo)者，并確保所有節(jié)點(diǎn)達(dá)成一致的共識(shí)。在Redis Sentinel中，通過Raft算法選舉領(lǐng)導(dǎo)者來實(shí)現(xiàn)Sentinel集群的協(xié)調(diào)和故障轉(zhuǎn)移。

Redis Sentinel的領(lǐng)導(dǎo)者選舉過程如下：

1. 候選者（Candidate）狀態(tài)：在Sentinel集群中，所有Sentinel節(jié)點(diǎn)都可以成為候選者。當(dāng)一個(gè)節(jié)點(diǎn)啟動(dòng)時(shí)，它會(huì)進(jìn)入候選者狀態(tài)，并向其他節(jié)點(diǎn)發(fā)送選舉請(qǐng)求。

2. 提名和投票：候選者向其他節(jié)點(diǎn)發(fā)送選舉請(qǐng)求，并提名自己作為領(lǐng)導(dǎo)者。收到選舉請(qǐng)求的節(jié)點(diǎn)可以投票贊成候選者，也可以拒絕投票。每個(gè)節(jié)點(diǎn)只能投一票，并在收到多數(shù)節(jié)點(diǎn)的贊成票后成為領(lǐng)導(dǎo)者。

3. 選舉過程：當(dāng)一個(gè)節(jié)點(diǎn)成為候選者后，它會(huì)等待其他節(jié)點(diǎn)的投票響應(yīng)。如果候選者收到多數(shù)節(jié)點(diǎn)的贊成票，它就會(huì)成為領(lǐng)導(dǎo)者。否則，如果候選者在一定時(shí)間內(nèi)沒有收到足夠的贊成票，它會(huì)放棄選舉，重新進(jìn)入候選者狀態(tài)。

4. 防止分裂：為了防止在網(wǎng)絡(luò)分區(qū)等情況下出現(xiàn)多個(gè)領(lǐng)導(dǎo)者，Redis Sentinel使用了Raft算法的領(lǐng)導(dǎo)者選舉機(jī)制。在選舉過程中，如果出現(xiàn)多個(gè)候選者同時(shí)成為領(lǐng)導(dǎo)者，它們會(huì)通過心跳機(jī)制來進(jìn)行競(jìng)爭(zhēng)，最終只有一個(gè)領(lǐng)導(dǎo)者能夠穩(wěn)定下來。

   心跳機(jī)制是Raft算法中用于維持領(lǐng)導(dǎo)者與跟隨者之間聯(lián)系和狀態(tài)同步的機(jī)制。一旦某個(gè)候選者成為領(lǐng)導(dǎo)者后，它會(huì)周期性地發(fā)送心跳消息給其他節(jié)點(diǎn)，其他節(jié)點(diǎn)會(huì)收到心跳消息后回復(fù)確認(rèn)消息，表示它們承認(rèn)該候選者為領(lǐng)導(dǎo)者。如果其他候選者沒有得到多數(shù)節(jié)點(diǎn)的贊成票或在選舉過程中沒有成為領(lǐng)導(dǎo)者，它們會(huì)繼續(xù)參與領(lǐng)導(dǎo)者的心跳競(jìng)爭(zhēng)，但由于沒有得到多數(shù)節(jié)點(diǎn)的確認(rèn)，它們最終不會(huì)穩(wěn)定地成為領(lǐng)導(dǎo)者。

5. 領(lǐng)導(dǎo)者維持：一旦選舉產(chǎn)生領(lǐng)導(dǎo)者，該領(lǐng)導(dǎo)者負(fù)責(zé)協(xié)調(diào)整個(gè)Sentinel集群的監(jiān)控和故障轉(zhuǎn)移工作。如果領(lǐng)導(dǎo)者節(jié)點(diǎn)宕機(jī)或離線，其他節(jié)點(diǎn)會(huì)重新進(jìn)行領(lǐng)導(dǎo)者選舉，選出新的領(lǐng)導(dǎo)者來代替。

通過Raft算法的領(lǐng)導(dǎo)者選舉機(jī)制，Redis Sentinel確保了在分布式環(huán)境中選舉出穩(wěn)定的領(lǐng)導(dǎo)者，從而保證了Sentinel集群的協(xié)調(diào)和故障轉(zhuǎn)移的可靠性和一致性。

三、cluster模式

Redis 主從復(fù)制可以實(shí)現(xiàn)讀寫分離，Redis Sentinel 模式可以實(shí)現(xiàn)自動(dòng)故障轉(zhuǎn)移，解決了 Redis 主從復(fù)制模式的高可用問題，看起來是個(gè)非常美好的方案。但 Sentinel 還是存在一個(gè)問題，那就是橫向擴(kuò)展問題。

在面對(duì)海量數(shù)據(jù)的時(shí)候，我們無法使用一個(gè) Redis Master 存儲(chǔ)全部數(shù)據(jù)，此時(shí)就需要一套分布式存儲(chǔ)方案將數(shù)據(jù)進(jìn)行切分，每個(gè) Redis 主從復(fù)制組只存儲(chǔ)一部分?jǐn)?shù)據(jù)，這樣就可以通過增加機(jī)器的方式增加 Redis 服務(wù)的整體存儲(chǔ)能力。

1.三種分片方案

客戶端分片、代理層分片以及 Redis Cluster 都是用于實(shí)現(xiàn) Redis 數(shù)據(jù)分片（Sharding）的方法。

1. 客戶端分片：

   • 原理：在客戶端分片中，應(yīng)用程序自行實(shí)現(xiàn)數(shù)據(jù)分片邏輯?？蛻舳烁鶕?jù)某種規(guī)則（如哈希函數(shù)、范圍等）將數(shù)據(jù)分散到不同的 Redis 節(jié)點(diǎn)?？蛻舳诵枰S護(hù)一張分片映射表，來決定每個(gè)鍵應(yīng)該存儲(chǔ)在哪個(gè) Redis 節(jié)點(diǎn)上。
   • 優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單，應(yīng)用程序可以根據(jù)業(yè)務(wù)需求定制化分片邏輯。
   • 缺點(diǎn)：增加了客戶端的開發(fā)和維護(hù)復(fù)雜性，對(duì)于節(jié)點(diǎn)動(dòng)態(tài)增減等情況需要手動(dòng)處理數(shù)據(jù)遷移。

2. 代理層分片：

   • 原理：在代理層分片中，應(yīng)用程序通過使用分片代理作為中間層，將數(shù)據(jù)的讀寫請(qǐng)求轉(zhuǎn)發(fā)給不同的 Redis 節(jié)點(diǎn)。代理層維護(hù)了分片映射表，根據(jù)鍵的哈希值或范圍來路由請(qǐng)求到相應(yīng)的 Redis 節(jié)點(diǎn)。
   • 優(yōu)點(diǎn)：客戶端無需關(guān)心分片邏輯，簡(jiǎn)化了應(yīng)用程序的實(shí)現(xiàn)，代理層處理了數(shù)據(jù)路由和節(jié)點(diǎn)動(dòng)態(tài)增減的問題。
   • 缺點(diǎn)：引入了額外的網(wǎng)絡(luò)開銷和代理層的維護(hù)成本。

3. Redis Cluster：

   • 原理：Redis Cluster 是 Redis 官方提供的分布式解決方案，基于一致性哈希算法進(jìn)行數(shù)據(jù)分片。Redis Cluster 使用一致性哈希分片的方式將數(shù)據(jù)分布到不同的 Redis 節(jié)點(diǎn)上，并通過 Gossip 協(xié)議實(shí)現(xiàn)節(jié)點(diǎn)之間的信息交換和故障檢測(cè)。
   • 優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單，自動(dòng)處理數(shù)據(jù)遷移和節(jié)點(diǎn)動(dòng)態(tài)增減，支持高可用性，可以容忍部分節(jié)點(diǎn)的故障。
   • 缺點(diǎn)：某些特殊場(chǎng)景下可能存在數(shù)據(jù)熱點(diǎn)問題，對(duì)于大規(guī)模的集群可能需要引入虛擬節(jié)點(diǎn)技術(shù)。

Redis Cluster 是推薦的 Redis 分片解決方案，它提供了較好的性能、可靠性和擴(kuò)展性，同時(shí)簡(jiǎn)化了開發(fā)和維護(hù)工作?？蛻舳朔制痛韺臃制瑒t更適用于一些特殊場(chǎng)景或自定義需求。

2.cluster模式

Redis Cluster 是 Redis 官方提供的分布式解決方案，用于將數(shù)據(jù)分布在多個(gè)節(jié)點(diǎn)上，實(shí)現(xiàn)數(shù)據(jù)的高可用性和橫向擴(kuò)展。其底層原理主要包括以下幾個(gè)方面：

1. 一致性哈希分片：

   • Redis Cluster 使用一致性哈希算法將鍵（Key）映射到一個(gè)固定大小的哈希槽（slot）上。Redis Cluster 中一共有 16384 個(gè)哈希槽，每個(gè)節(jié)點(diǎn)負(fù)責(zé)一部分槽的數(shù)據(jù)。根據(jù)鍵的哈希值，集群中的每個(gè)節(jié)點(diǎn)都能確定應(yīng)該接管哪些槽的數(shù)據(jù)。

2. 節(jié)點(diǎn)通信與故障檢測(cè)：

   • Redis Cluster 中的每個(gè)節(jié)點(diǎn)都與其他節(jié)點(diǎn)保持持續(xù)的通信，使用 Gossip 協(xié)議進(jìn)行信息交換。節(jié)點(diǎn)之間通過發(fā)送 PING、PONG 消息來檢測(cè)對(duì)方是否在線，從而實(shí)現(xiàn)故障檢測(cè)。
   • 當(dāng)一個(gè)節(jié)點(diǎn)發(fā)現(xiàn)另一個(gè)節(jié)點(diǎn)不可用（無法收到 PING 回復(fù)），它會(huì)將該節(jié)點(diǎn)標(biāo)記為下線，然后通過集群中其他節(jié)點(diǎn)來確認(rèn)故障。一旦多個(gè)節(jié)點(diǎn)都確認(rèn)某個(gè)節(jié)點(diǎn)下線，Redis Cluster 就會(huì)進(jìn)行故障轉(zhuǎn)移，選舉一個(gè)新的主節(jié)點(diǎn)來接管失效節(jié)點(diǎn)的哈希槽。

3. 主從復(fù)制：

   • Redis Cluster 中的每個(gè)主節(jié)點(diǎn)都可以有多個(gè)從節(jié)點(diǎn)。主從復(fù)制機(jī)制用于保障數(shù)據(jù)的冗余和高可用性。
   • 當(dāng)一個(gè)主節(jié)點(diǎn)下線時(shí)，它的一個(gè)從節(jié)點(diǎn)會(huì)被晉升為新的主節(jié)點(diǎn)，繼續(xù)處理客戶端請(qǐng)求。這樣可以確保數(shù)據(jù)的持久性和高可用性。

4. 數(shù)據(jù)遷移：

   • Redis Cluster 允許節(jié)點(diǎn)動(dòng)態(tài)增減。當(dāng)新增節(jié)點(diǎn)加入集群時(shí)，其他節(jié)點(diǎn)會(huì)將一部分哈希槽的數(shù)據(jù)遷移到新節(jié)點(diǎn)上，以平衡負(fù)載。
   • 數(shù)據(jù)遷移通過異步傳輸（開啟一個(gè)子線程），源節(jié)點(diǎn)將數(shù)據(jù)發(fā)送給目標(biāo)節(jié)點(diǎn)，并在數(shù)據(jù)遷移完成后，確認(rèn)數(shù)據(jù)同步成功。在數(shù)據(jù)遷移過程中，不會(huì)停止處理客戶端請(qǐng)求。

5. 客戶端路由：

   • 客戶端通過連接到任意一個(gè)節(jié)點(diǎn)來訪問整個(gè) Redis Cluster。當(dāng)客戶端發(fā)送請(qǐng)求時(shí)，節(jié)點(diǎn)會(huì)根據(jù)鍵的哈希值來路由請(qǐng)求到相應(yīng)的節(jié)點(diǎn)，從而保證數(shù)據(jù)的一致性。

Redis Cluster 的底層原理主要依賴于一致性哈希分片和節(jié)點(diǎn)之間的通信與協(xié)作。它通過集群中多個(gè)節(jié)點(diǎn)的協(xié)作來實(shí)現(xiàn)數(shù)據(jù)的高可用性和分布式存儲(chǔ)。在集群中節(jié)點(diǎn)的動(dòng)態(tài)增減、數(shù)據(jù)遷移和故障轉(zhuǎn)移等過程都是自動(dòng)化的，使得 Redis Cluster 成為一個(gè)高性能、高可用性的分布式數(shù)據(jù)庫(kù)解決方案。文章來源地址http://www.zghlxwxcb.cn/news/detail-633132.html

到了這里，關(guān)于Redis追本溯源（四）集群：主從模式、哨兵模式、cluster模式的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！