文章目錄

• 主從同步(復(fù)制）
• • 同步
  • 命令傳播
  • 優(yōu)缺點
• 哨兵
• • 下線判斷與選舉
  • 故障轉(zhuǎn)移
• 集群
• • 握手
  • 分片

---

主從同步(復(fù)制）

主從同步是Redis高可用服務(wù)的基石，其將主要存儲數(shù)據(jù)的服務(wù)器成為主服務(wù)器(master)，把對主服務(wù)器進行復(fù)制的服務(wù)器成為從服務(wù)器(slave)。

并且從節(jié)點還可以是其他服務(wù)器的主節(jié)點，并且擁有屬于自己的從節(jié)點

通過主從模式來進行讀寫的分離，主服務(wù)器進行寫操作，然后將數(shù)據(jù)同步給從服務(wù)器，讓從服務(wù)器來進行讀操作，通過這種模式來分攤主服務(wù)器的壓力。

---

Redis的復(fù)制功能主要分為同步(sync)與命令傳播(command propagate) 兩個操作

同步

同步操作用于將從服務(wù)器的數(shù)據(jù)庫狀態(tài)更新至主服務(wù)器當前的數(shù)據(jù)庫狀態(tài)。

在從服務(wù)器對主服務(wù)器進行復(fù)制之前，需要先將從服務(wù)器的數(shù)據(jù)庫狀態(tài)更新至主服務(wù)器的服務(wù)器狀態(tài)

命令傳播

命令傳播操作用于在主服務(wù)器的數(shù)據(jù)庫狀態(tài)發(fā)生變化(執(zhí)行寫命令)，導(dǎo)致主從服務(wù)器的數(shù)據(jù)庫狀態(tài)不一致時，讓主從服務(wù)器的數(shù)據(jù)庫重新回到一致狀態(tài)。

當客戶端對主服務(wù)器進行寫操作后，此時主從服務(wù)器的數(shù)據(jù)庫狀態(tài)就會不一致。

為了能夠再次讓主從服務(wù)器的數(shù)據(jù)庫狀態(tài)恢復(fù)一致，此時主服務(wù)器會將同一命令發(fā)送給從服務(wù)器，當從服務(wù)器執(zhí)行完改命令時，數(shù)據(jù)庫狀態(tài)再次恢復(fù)一致。

優(yōu)缺點

優(yōu)點

• 性能方面：可以實現(xiàn)讀寫的分離，由主服務(wù)器來進行寫操作，并將寫的結(jié)果同步至從服務(wù)器，由從服務(wù)器來進行讀操作，這樣就能將壓力分攤到各個服務(wù)器上
• 高可用：當主服務(wù)器宕機之后，可以通過故障轉(zhuǎn)移機制將從節(jié)點提升為主節(jié)點，快速的進行服務(wù)器的宕機恢復(fù)。
• 防止數(shù)據(jù)丟失：當主服務(wù)器的磁盤損壞或者數(shù)據(jù)丟失后，因為從服務(wù)器還保留相關(guān)的數(shù)據(jù)，不至于導(dǎo)致數(shù)據(jù)全部丟失

缺點

• 由于主從同步需要人工管理，主節(jié)點崩潰后需要人工進行從節(jié)點的提升才能恢復(fù)Redis的正常使用

---

從上面可以看到，主從同步并沒有一個自動的管理機制，當出現(xiàn)主服務(wù)器宕機的情況，需要人工干預(yù)來進行恢復(fù)，但是如果主從服務(wù)器數(shù)量龐大，又或是因為高并發(fā)導(dǎo)致的大量崩潰，這時需要的時間和難度都是非常大的，于是Redis中又引入了**哨兵模式(Sentinel)**來作為解決方案，將管理由人工轉(zhuǎn)向哨兵，使得Redis具有自動容災(zāi)恢復(fù)的能力

哨兵

哨兵是Redis高可用性的解決方案，通過一個或者多個哨兵組成的哨兵系統(tǒng)，可以監(jiān)控任意多個主服務(wù)器以及它們的從服務(wù)器。當某個被監(jiān)視的主服務(wù)器進入下線狀態(tài)時，哨兵就會自動將下線主服務(wù)器的某個從服務(wù)器升級為新的主服務(wù)器，然后由新的主服務(wù)器繼續(xù)處理命令請求

總結(jié)下來就是哨兵模式可以用來監(jiān)控主從同步服務(wù)器節(jié)點，并在主從服務(wù)器出現(xiàn)問題的時候?qū)崿F(xiàn)自動容災(zāi)恢復(fù)

下線判斷與選舉

由于一個主服務(wù)器可能會同時被多個哨兵進行同時進行監(jiān)控，所以當一個哨兵主觀的將其判定為下線時，為了確保這個主服務(wù)器真的下線了，它會向同樣監(jiān)視這一主服務(wù)器的其他哨兵進行詢問，看看它們是否也認為該服務(wù)器下線了，當積累到一定數(shù)量的下線判斷時，此時就會客觀認為主服務(wù)器下線，開始進行故障轉(zhuǎn)移。

但是故障轉(zhuǎn)移只能由一個哨兵來進行，所以此時所有監(jiān)控該服務(wù)器的哨兵會進行協(xié)商，選舉出一個領(lǐng)頭哨兵來進行故障轉(zhuǎn)移。

每一個哨兵都會向其他哨兵發(fā)送一個帶有自己運行ID的命令，如果接收到該命令的哨兵還沒有進行投票，就會將該ID設(shè)置為它的頭領(lǐng)ID，并返回一個確認恢復(fù)。通過這種方法每一個哨兵都可以直到有多少個人為其投票，并選出一個票數(shù)最高的作為頭領(lǐng)哨兵

故障轉(zhuǎn)移

故障轉(zhuǎn)移分為以下三個步驟

在已下線主服務(wù)器的從服務(wù)器中挑選一個出來作為新的主服務(wù)器

在已下線主服務(wù)器的從服務(wù)器改為復(fù)制新的主服務(wù)器

將已下線主服務(wù)器設(shè)置為新的主服務(wù)器的從服務(wù)器，當這個舊的主服務(wù)器重新上線時，他就會成為新的主服務(wù)器的從服務(wù)器

---

集群

集群(Cluster)是Redis多機運行中最完美的方案 ，它的出現(xiàn)甚至可以讓我們拋棄掉主從同步和哨兵來實現(xiàn)Redis多機的運行。

集群是無代理模式去中心化的運行模式，客戶端發(fā)送的絕大多數(shù)命令會直接交給相關(guān)節(jié)點執(zhí)行，大部分情況下請求命令不需要轉(zhuǎn)發(fā)，或者僅僅只需要轉(zhuǎn)發(fā)一次就能完成請求和響應(yīng)。所以集群中的單個節(jié)點的性能與單機Redis服務(wù)器的性能非常接近，并且通過水平拓展能夠使得性能進行翻倍，所以集群的性能非常的高

由于主從同步只能有一個主節(jié)點，而集群可以擁有無數(shù)個主從節(jié)點，有著更強大的平行拓展能力。
所以在理論情況下，如果水平拓展一倍的主節(jié)點，相當于請求處理的性能也提高了一倍，也就是說通過平行拓展N倍的主從節(jié)點，就會比單機服務(wù)來說性能提升了N倍。

握手

每個節(jié)點其實就是運行在集群模式下的Redis服務(wù)器，而這些節(jié)點在一開始時都是互相獨立的，它們都處于一個只包含自己的集群中，要組建一個真正可以工作的集群，我們就必須要將各個獨立的節(jié)點通過握手的方式連接起來。

分片

集群通過分片的方式來保存數(shù)據(jù)庫中的鍵值對。
集群的整個數(shù)據(jù)庫被分為個16384個槽，并且將一個或者多個槽指派給某個節(jié)點，讓這個節(jié)點來負責管理這個槽中的數(shù)據(jù)以及相關(guān)命令，通過這種方法就能很好的進行壓力的分攤。

節(jié)點之間會互相轉(zhuǎn)遞指派槽的信息



對于發(fā)送來的命令，會通過其所在的槽來分配至對應(yīng)的節(jié)點，如果分配錯誤，也會通過轉(zhuǎn)向操作來轉(zhuǎn)交給至正確的節(jié)點

總結(jié)

以上是生活随笔為你收集整理的Redis 多机服务 ： 主从同步、哨兵、集群的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。