一文帶你了解Redis的三種集群模式

更新時間：2023年06月09日 10:42:28 作者：不肯過江東丶

Redis?的常用的集群方式主要有以下三種，分別是主從復制模式、哨兵模式、Redis-Cluster集群模式，那么下面我們就分別了解一下這三種集群模式的優(yōu)點與缺點

Redis 的三種集群模式

Redis 的常用的集群方式主要有以下三種，分別是主從復制模式、哨兵模式、Redis-Cluster集群模式，那么下面我們就分別了解一下這三種集群模式的優(yōu)點與缺點。

主從復制模式

主從復制，是指將一臺 Redis 服務器的數(shù)據(jù)，復制到其他的 Redis 服務器。前者稱為主節(jié)點（Master），后者稱為從節(jié)點（Slave），數(shù)據(jù)的復制是單向的，只能由主節(jié)點到從節(jié)點。Redis 的主從復制模式一般是由一主一從（一個主節(jié)點+一個從節(jié)點）或一主多從（一個主節(jié)點+多個從節(jié)點）的形式來構(gòu)成。主節(jié)點負責寫操作，從節(jié)點負責讀操作，從節(jié)點從主節(jié)點復制數(shù)據(jù)，通過這種方式也可以實現(xiàn)讀寫分離。

下面我們一起看看主從復制的原理 ??

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

了解了主從復制模式的概念和原理后，我們一起總結(jié)一下主從復制模式的優(yōu)缺點：

??優(yōu)點??
1、支持主從復制，主機會自動將數(shù)據(jù)同步到從機，可以進行讀寫分離，同時緩解了主庫的壓力。
2、Master Server 是以非阻塞的方式為 Slaves 提供服務。所以在 Master-Slave 同步期間，客戶端仍然可以提交查詢或修改請求；Slave Server 同樣是以非阻塞的方式完成數(shù)據(jù)同步。在同步期間，如果有客戶端提交查詢請求，Redis則返回同步之前的數(shù)據(jù)。

??缺點??
1、由于 Redis 不具備自動容錯和恢復功能，主機從機的宕機都會導致部分讀寫請求失敗，需要等待機器重啟或者手動將某臺從節(jié)點升級為主節(jié)點才能解決。而且在主機宕機時，宕機前部分數(shù)據(jù)未能及時同步到從機，切換IP后還會引入數(shù)據(jù)不一致的問題，降低了系統(tǒng)的可用性。

我們看完主從復制模式后，可能有些小伙伴就發(fā)現(xiàn)了一些問題：主從復制模式下，當主節(jié)點宕機后，需要手動將某臺從節(jié)點切換為主節(jié)點，這需要人工干預，不僅費時費力，而且還會造成一段時間內(nèi)服務不可用，這個問題該如何解決呢?? 接下來就需要請哨兵模式登場了....

哨兵模式

為了解決我們剛剛談到的問題，Redis 2.8 中提供了哨兵工具來實現(xiàn)自動化的系統(tǒng)監(jiān)控和故障恢復功能。其實哨兵模式也是一種主從復制模式，只不過增加了哨兵的功能，哨兵的功能主要有兩點：第一是監(jiān)控主服務器和從服務器是否正常運行；第二是當主節(jié)點出現(xiàn)故障時自動將從節(jié)點轉(zhuǎn)換為主節(jié)點。

哨兵的啟動依賴于主從模式，所以須把主從模式安裝好的情況下再去做哨兵模式，所有節(jié)點上都需要部署哨兵模式，哨兵模式會監(jiān)控所有的 Redis 工作節(jié)點是否正常，當 Master （主節(jié)點）出現(xiàn)問題的時候，因為其他節(jié)點與主節(jié)點失去聯(lián)系，因此會進行投票，投票過半就認為這個 Master （主節(jié)點）的確出現(xiàn)問題，然后會通知其他哨兵，并從 Slaves （從節(jié)點）中選取一個作為新的 Master（主節(jié)點）。既然涉及到了投票過半的要求，那么參與投票的哨兵就必須為單數(shù)，即整個運行哨兵的集群的數(shù)量?不得少于3個節(jié)點?。在選取新的主節(jié)點的過程中，我們又可以將整個過程細分為兩步，分別為“選哨兵領導”和“由哨兵領導推舉主節(jié)點”。

?? 第一步：選哨兵領導 ??
哨兵A： 哎哎哎?。。⌒值軅儯野l(fā)現(xiàn)主節(jié)點掉了?。。?！你們趕緊選我當頭，我去選一個新的子節(jié)點來做主節(jié)點！??！
哨兵B： 額...行吧，我選你當頭，雖然我很想當領導，但是也沒啥經(jīng)驗呢，還是你來吧。
哨兵C： 不行??！我不支持你，我才是當領導的材料??！
哨兵A： 哨兵C你去一邊子的，咱們就三個兄弟，我和哨兵B都支持，那我就是領導了??

P.S. 如果此時有多個哨兵同時參選，則在等待任意時間后重新發(fā)起投票，直到選出了領頭的

?? 第二步：哨兵領導選擇主節(jié)點 ??
哨兵A： 我來看看以前的領導留下來的《如何選擇主節(jié)點》里是怎么寫的...翻書ing... 根據(jù)書里的記載，我需要按照健康性（哨兵發(fā)送ping命令后的響應時間長短，時間越短則越健康）、完整性（選擇復制偏移量最大，也就是復制最完整的從節(jié)點）、優(yōu)先級高低（選擇配置文件中從節(jié)點優(yōu)先級配置最高的，即replica-priority，其默認值為100）來進行主節(jié)點的挑選工作，如果有兩個從節(jié)點都具備這三個條件的話，那就根據(jù)節(jié)點啟動時分配的 run id 來決定誰做主節(jié)點（runid越小越有可能被選擇為主節(jié)點）...
哨兵A： 還是查書有用啊，要不我還真不知道怎么干，我去選主節(jié)點啦~~

P.S. 選擇主節(jié)點的過程又稱為故障轉(zhuǎn)移的過程

這里有一點是需要注意的，哨兵的下線分為兩種，分別是主觀下線（我認為你掉線了）和客觀下線（我們認為你掉線了）。每個哨兵節(jié)點每隔1秒會向主節(jié)點、從節(jié)點及其它哨兵節(jié)點發(fā)送一次 ping 命令做一次心跳檢測。如果主節(jié)點在一定時間范圍內(nèi)不回復或者是回復一個錯誤消息，那么這個哨兵就會認為這個主節(jié)點主觀下線了(單方面的）。當超過半數(shù)哨兵節(jié)點認為該主節(jié)點主觀下線了，這樣就客觀下線了。客觀下線是針對于主節(jié)點來說的概念，也就是說只有發(fā)生了客觀下線，才會執(zhí)行我們上面所說的兩個步驟；如果從節(jié)點和哨兵節(jié)點發(fā)生故障，被哨兵主觀下線后，則不會再有后續(xù)的客觀下線和故障轉(zhuǎn)移操作。

通過上面的講解，我們也就可以總結(jié)出哨兵模式的優(yōu)點了：哨兵模式是基于主從模式的，所有主從的優(yōu)點，哨兵模式都具有，同時使用哨兵模式后主從節(jié)點可以自動切換，可以讓系統(tǒng)更健壯，可用性更高。

Redis-Cluster集群模式

Redis 的哨兵模式基本已經(jīng)可以實現(xiàn)高可用，讀寫分離，但是在這種模式下每臺 Redis 服務器都存儲相同的數(shù)據(jù)，很浪費內(nèi)存，所以在 Redis3.0 上加入了 Cluster 模式，實現(xiàn)的 Redis 的分布式存儲，即每臺 Redis 節(jié)點（Node）上存儲不同的內(nèi)容，很大程度上節(jié)約了內(nèi)容。需要注意的是，集群中的節(jié)點也是分為主節(jié)點和從節(jié)點的，只有主節(jié)點負責讀寫請求和集群信息的維護，而從節(jié)點只進行主節(jié)點數(shù)據(jù)和狀態(tài)信息的復制。Redis-Cluster采用無中心結(jié)構(gòu),它有以下三個特點 ??

① 所有的redis節(jié)點彼此互聯(lián)(PING-PONG機制),內(nèi)部使用二進制協(xié)議優(yōu)化傳輸速度和帶寬。
②節(jié)點的失效（下線）是通過集群中超過半數(shù)的節(jié)點檢測失效時才生效。
③ 客戶端與 Redis 節(jié)點直連，不需要中間代理層，客戶端不需要連接集群所有節(jié)點，連接集群中任何一個可用節(jié)點即可。

接下來我們一起看看 Redis-Cluster 集群模式的工作流程：

在 Redis 的每一個節(jié)點上，都有這么兩個小東西，一個是插槽（slot），它的的取值范圍是：0-16383，另一個就是cluster，可以理解為是一個集群管理的插件。當 Redis 拿到了需要存取的 key 時，Redis 會根據(jù) CRC16 算法得出一個結(jié)果，然后把結(jié)果對 16384 求余數(shù)，這樣每個 key 都會對應一個編號在 0-16383 之間的哈希槽，通過這個值，去找到對應的插槽所對應的節(jié)點，然后直接自動跳轉(zhuǎn)到這個對應的節(jié)點上進行存取操作。為了保證高可用，Redis-Cluster 集群引入了主從模式，一個主節(jié)點對應一個或者多個從節(jié)點，當主節(jié)點宕機的時候，就會啟用從節(jié)點。

雖說 Redis-Cluster 集群引入了主從模式，但是也帶來了一個問題：如果集群中具有A、B、C三個節(jié)點，如果節(jié)點B失敗了，整個集群就會因缺少5461-10922這個范圍的插槽而不可使用；如果為每個節(jié)點添加一個從節(jié)點A1、B1、C1整個集群便有三個Master節(jié)點和三個slave節(jié)點組成，當在節(jié)點B失敗后，那么集群選舉B1位為主節(jié)點繼續(xù)服務。但是當B和B1都失敗后，集群將不可用。

有些小伙伴看到這里可能會產(chǎn)生一個疑問：為什么插槽數(shù)是16384個呢？為什么不能是65535或者是其他數(shù)值呢？其實關于這個問題，作者已經(jīng)給了我們一個回復??

The reason is:

Normal heartbeat packets carry the full configuration of a node, that can be replaced in an idempotent way with the old in order to update an old config. This means they contain the slots configuration for a node, in raw form, that uses 2k of space with16k slots, but would use a prohibitive 8k of space using 65k slots.
At the same time it is unlikely that Redis Cluster would scale to more than 1000 mater nodes because of other design tradeoffs.

So 16k was in the right range to ensure enough slots per master with a max of 1000 maters, but a small enough number to propagate the slot configuration as a raw bitmap easily. Note that in small clusters the bitmap would be hard to compress because when N is small the bitmap would have slots/N bits set that is a large percentage of bits set.

用一句話總結(jié)出來就是：由于 Redis 節(jié)點之間通訊會相互交換槽信息，那如果槽過多（意味著網(wǎng)絡包會變大），網(wǎng)絡包變大，就意味著會過度占用網(wǎng)絡的帶寬，同時作者認為 Redis 集群中節(jié)點數(shù)不會超過1000個，所以作者就取了16384這個數(shù)，即可以將數(shù)據(jù)合理打散至 Redis 集群中的不同實例，又不會在交換數(shù)據(jù)時導致帶寬占用過多。