Redis三種集群方式：主從復(fù)制、哨兵模式和Cluster模式

一、主從復(fù)制模式

Redis配置成主從模式，主庫(Master)只負(fù)責(zé)客戶端的寫數(shù)據(jù)，從庫(Slave)只負(fù)責(zé)客戶端的讀數(shù)據(jù)。

主從數(shù)據(jù)復(fù)制過程如圖所示：

主從復(fù)制原理：

• slave redis連接master redis，發(fā)送sync命令；
• master redis接收到sync命名后，執(zhí)行BGSAVE命令生成RDB文件,使用緩沖區(qū)記錄此后執(zhí)行的所有寫命令；
• master redis BGSAVE執(zhí)行完后，向所有slave redis發(fā)送快照文件，并在發(fā)送期間繼續(xù)記錄被執(zhí)行的寫命令；
• slave redis收到快照文件后丟棄所有舊數(shù)據(jù)，載入收到的快照；
• master redis快照發(fā)送完畢后開始向slave redis發(fā)送緩沖區(qū)中的寫命令；
• slave redis器完成對快照的載入，開始接收命令請求，并執(zhí)行來自master redis緩沖區(qū)的寫命令；
• master redis每執(zhí)行一個寫命令就會向slave redis發(fā)送相同的寫命令，slave redis接收并執(zhí)行收到的寫命令

主從復(fù)制優(yōu)缺點：

優(yōu)點：

• 實現(xiàn)讀寫分離：客戶端從master redis寫數(shù)據(jù)，從slave redis讀數(shù)據(jù)
• 支持主從復(fù)制:master redis自動將數(shù)據(jù)同步到slave redis
• Slave分載Master的同步壓力:slave可以接受其它Slaves的連接和同步請求
• Master Server是以非阻塞的方式為Slaves提供服務(wù)：在Master-Slave同步期間，客戶端仍然可以提交查詢或修改請求
• Slave Server同樣是以非阻塞的方式完成數(shù)據(jù)同步：在同步期間，如果有客戶端提交查詢請求，Redis則返回同步之前的數(shù)據(jù)

缺點：

• 不具備自動容錯和恢復(fù)功能：主機從機的宕機都會導(dǎo)致前端部分讀寫請求失敗，需要等待機器重啟或者手動切換前端的IP才能恢復(fù)；宕機前有部分?jǐn)?shù)據(jù)未能及時同步到從機，切換IP后還會引入數(shù)據(jù)不一致的問題，降低了系統(tǒng)的可用性
• 較難支持在線擴容：在集群容量達到上限時在線擴容會變得很復(fù)雜。

二、哨兵模式

哨兵模式：

在主從復(fù)制模式中當(dāng)主服務(wù)器中斷服務(wù)后，需要人工手動操作來將一個從服務(wù)器升級為主服務(wù)器，以便繼續(xù)提供服務(wù)。而哨兵模式可以實現(xiàn)自動化的系統(tǒng)監(jiān)控和故障恢復(fù)功能。

哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的進程，作為進程，它會獨立運行。其原理是哨兵通過發(fā)送命令，等待Redis服務(wù)器響應(yīng)，從而監(jiān)控運行的多個Redis實例。

哨兵的作用:

• 監(jiān)控主服務(wù)器和從服務(wù)器是否正常運行。
• 主服務(wù)器出現(xiàn)故障時自動將從服務(wù)器轉(zhuǎn)換為主服務(wù)器

故障切換(failover)過程:

假設(shè)主服務(wù)器宕機，哨兵1先檢測到這個結(jié)果，系統(tǒng)并不會馬上進行failover過程，僅僅是哨兵1主觀的認(rèn)為主服務(wù)器不可用，這個現(xiàn)象成為主觀下線。當(dāng)后面的哨兵也檢測到主服務(wù)器不可用，并且數(shù)量達到一定值時，那么哨兵之間就會進行一次投票，投票的結(jié)果由一個哨兵發(fā)起，進行failover操作。切換成功后，就會通過發(fā)布訂閱模式，讓各個哨兵把自己監(jiān)控的從服務(wù)器實現(xiàn)切換主機，這個過程稱為客觀下線。這樣對于客戶端而言，一切都是透明的。

哨兵除了監(jiān)控服務(wù)器，哨兵之間也相互監(jiān)控，如下圖所示：

哨兵模式的優(yōu)缺點

優(yōu)點：

• 基于主動復(fù)制模式，主從復(fù)制模式的所有優(yōu)點都有
• 主從可以自動切換，系統(tǒng)更健壯，可用性更高

缺點：

• 很難支持在線擴容，在線擴容復(fù)雜

三、Redis-Cluster集群

現(xiàn)在很多公司采用的是這種redis集群模式。

redis的哨兵模式基本已經(jīng)可以實現(xiàn)高可用，讀寫分離 ，但是在這種模式下每臺redis服務(wù)器都存儲相同的數(shù)據(jù)，很浪費內(nèi)存，所以在redis3.0上加入了cluster模式，實現(xiàn)的redis的分布式存儲，也就是說每臺redis節(jié)點上存儲不同的內(nèi)容。解決了前面哨兵模式擴容復(fù)雜的問題。

Cluster集群模式是在哨兵模式的基礎(chǔ)上進行升級改造：

• 集群節(jié)點復(fù)制：遵循前面講到的主從復(fù)制模式的節(jié)點復(fù)制方式
• 故障轉(zhuǎn)移：和前面講到的哨兵模式進行故障轉(zhuǎn)移的方法基本一樣，不同的是，在集群里面，故障轉(zhuǎn)移是由集群中其他在線的主節(jié)點負(fù)責(zé)進行的，所以集群不必另外使用Redis Sentinel。
• 集群分片策略： 每臺redis節(jié)點上存儲不同的內(nèi)容

Redis Cluster的具體實現(xiàn)細(xì)節(jié)：

采用了Hash槽的概念，集群會預(yù)先分配16384個槽，并將這些槽分配給具體的服務(wù)節(jié)點，通過對Key進行CRC16(key)%16384運算得到對應(yīng)的槽是哪一個，從而將讀寫操作轉(zhuǎn)發(fā)到該槽所對應(yīng)的服務(wù)節(jié)點。當(dāng)有新的節(jié)點加入或者移除的時候，再來遷移這些槽以及其對應(yīng)的數(shù)據(jù)。在這種設(shè)計之下，我們可以很方便的進行動態(tài)擴容或縮容，目前很多公司都傾向于這種集群模式。

如下圖所示：

面試不可怕，掌握真正的精髓可以讓你一擊即中。

更多學(xué)習(xí)過程中筆記源碼分享

評論留言+轉(zhuǎn)發(fā)文章+關(guān)注我后私信回復(fù)【Java】即可免費獲取我準(zhǔn)備好的面試文檔資料！

總結(jié)

以上是生活随笔為你收集整理的k8s 手动恢复redis 集群_高工面试之：redis的几种集群方式你都熟悉吗？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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