大家好，我是樓仔！

Redis 的高可用，太重要啦！之前找工作面試，這個(gè)問(wèn)題面試的頻率都能排到前幾，尤其是一些大廠，先不要著急看文章，如果面試官給你拋這么個(gè)問(wèn)題，你會(huì)怎么回答呢，可以先想 5 分鐘。

這里要等待 5 分鐘 ...

其實(shí)我也可以偷個(gè)懶，完全轉(zhuǎn)載其它博客，但是沒(méi)有找到我想要的，為了不辜負(fù)廣大粉絲，樓哥還是單獨(dú)給大家寫一篇，主要根據(jù)這塊知識(shí)，再結(jié)合之前的一些面試情況，給大家嘮嘮。

1. Redis 分片策略

1.1 Hash 分片

我們都知道，對(duì)于 Reids 集群，我們需要通過(guò) hash 策略，將 key 打在 Redis 的不同分片上。

假如我們有 3 臺(tái)機(jī)器，常見(jiàn)的分片方式為 hash(IP)%3，其中 3 是機(jī)器總數(shù)。

目前很多小公司都這么玩，上手快，簡(jiǎn)單粗暴，但是這種方式有一個(gè)致命的缺點(diǎn)：當(dāng)增加或者減少緩存節(jié)點(diǎn)時(shí)，總節(jié)點(diǎn)個(gè)數(shù)發(fā)生變化，導(dǎo)致分片值發(fā)生改變，需要對(duì)緩存數(shù)據(jù)做遷移。

那如何解決該問(wèn)題呢，答案是一致性 Hash。

1.2 一致性 Hash

一致性哈希算法是 1997 年由麻省理工學(xué)院提出的一種分布式哈希實(shí)現(xiàn)算法。

環(huán)形空間：按照常用的 hash 算法來(lái)將對(duì)應(yīng)的 key 哈希到一個(gè)具有 2^32 次方個(gè)桶的空間中，即 0~(2^32)-1 的數(shù)字空間中，現(xiàn)在我們可以將這些數(shù)字頭尾相連，想象成一個(gè)閉合的環(huán)形。

Key 散列 Hash 環(huán)：現(xiàn)在我們將 object1、object2、object3、object4 四個(gè)對(duì)象通過(guò)特定的 Hash 函數(shù)計(jì)算出對(duì)應(yīng)的 key 值，然后散列到 Hash 環(huán)上。

機(jī)器散列 Hash 環(huán)：假設(shè)現(xiàn)在有 NODE1、NODE2、NODE3 三臺(tái)機(jī)器，以順時(shí)針的方向計(jì)算，將所有對(duì)象存儲(chǔ)到離自己最近的機(jī)器中，object1 存儲(chǔ)到了 NODE1，object3 存儲(chǔ)到了 NODE2，object2、object4 存儲(chǔ)到了 NODE3。

節(jié)點(diǎn)刪除：如果 NODE2 出現(xiàn)故障被刪除了，object3 將會(huì)被遷移到 NODE3 中，這樣僅僅是 object3 的映射位置發(fā)生了變化，其它的對(duì)象沒(méi)有任何的改動(dòng)。

添加節(jié)點(diǎn)：如果往集群中添加一個(gè)新的節(jié)點(diǎn) NODE4，object2 被遷移到了 NODE4 中，其它對(duì)象保持不變。

通過(guò)對(duì)節(jié)點(diǎn)的添加和刪除的分析，一致性哈希算法在保持了單調(diào)性的同時(shí)，還使數(shù)據(jù)的遷移達(dá)到了最小，這樣的算法對(duì)分布式集群來(lái)說(shuō)是非常合適的，避免了大量數(shù)據(jù)遷移，減小了服務(wù)器的的壓力。

如果機(jī)器個(gè)數(shù)太少，為了避免大量數(shù)據(jù)集中在幾臺(tái)機(jī)器，實(shí)現(xiàn)平衡性，可以建立虛擬節(jié)點(diǎn)（比如一臺(tái)機(jī)器建立 3-4 個(gè)虛擬節(jié)點(diǎn)），然后對(duì)虛擬節(jié)點(diǎn)進(jìn)行 Hash。

2. 高可用方案

很多時(shí)候，公司只給我們提供一套 Redis 集群，至于如何計(jì)算分片，我們一般有 2 套成熟的解決方案。

客戶端方案：也就是客戶端自己計(jì)算 Redis 分片，無(wú)論你使用Hash 分片，還是一致性 Hash，都是由客戶端自己完成。

客戶端方案簡(jiǎn)單粗暴，但是只能在單一語(yǔ)言系統(tǒng)之間復(fù)用，如果你使用的是 PHP 的系統(tǒng)，后來(lái) Java 也需要使用，你需要用 Java 重新寫一套分片邏輯。

為了解決多語(yǔ)言、不同平臺(tái)復(fù)用的問(wèn)題，就衍生出中間代理層方案。

中間代理層方案：將客戶端解決方案的經(jīng)驗(yàn)移植到代理層中，通過(guò)通用的協(xié)議（如 Redis 協(xié)議）來(lái)實(shí)現(xiàn)在其他語(yǔ)言中的復(fù)用，用戶無(wú)需關(guān)心緩存的高可用如何實(shí)現(xiàn)，只需要依賴你的代理層即可。

代理層主要負(fù)責(zé)讀寫請(qǐng)求的路由功能，并且在其中內(nèi)置了一些高可用的邏輯。

你可以看看，你們公司的 Redis 使用的是哪種方案呢？對(duì)于“客戶端方案”，其實(shí)有的也不用自己去寫，比如負(fù)責(zé)維護(hù) Redis 的部門會(huì)提供不同語(yǔ)言的 SDK，你只需要去集成對(duì)應(yīng)的 SDK 即可。

3. 高可用原理

3.1 Redis 主從

Redis 基本都通過(guò)“主 - 從”模式進(jìn)行部署，主從庫(kù)之間采用的是讀寫分離的方式。

同 MySQL 類似，主庫(kù)支持寫和讀，從庫(kù)只支持讀，數(shù)據(jù)會(huì)先寫到主庫(kù)，然后定時(shí)同步給從庫(kù)，具體的同步規(guī)則，主要將 RDB 日志從主庫(kù)同步給從庫(kù)，然后從庫(kù)讀取 RDB 日志，這里比較復(fù)雜，其中還涉及到 replication buffer，就不再展開(kāi)。

這里有個(gè)問(wèn)題，一次同步過(guò)程中，主庫(kù)需要完成 2 個(gè)耗時(shí)操作：生成 RDB 文件和傳輸 RDB 文件。

如果從庫(kù)數(shù)量過(guò)多，主庫(kù)忙于 fock 子進(jìn)程生成 RDB 文件和數(shù)據(jù)同步，會(huì)阻塞主庫(kù)正常請(qǐng)求。

這個(gè)如何解決呢？答案是 “主 - 從 - 從” 模式。

為了避免所有從庫(kù)都從主庫(kù)同步 RDB 日志，可以借助從庫(kù)來(lái)完成同步：比如新增 3、4 兩個(gè) Slave，可以等 Slave 2 同步完后，再通過(guò) Slave 2 同步給 Slave 3 和 Slave 4。

如果我是面試官，我可能會(huì)繼續(xù)問(wèn)，如果數(shù)據(jù)同步了 80%，網(wǎng)絡(luò)突然終端，當(dāng)網(wǎng)絡(luò)后續(xù)又恢復(fù)后，Redis 會(huì)如何操作呢？

3.2 Redis 分片

這個(gè)有點(diǎn)像 MySQL 分庫(kù)分表，將數(shù)據(jù)存儲(chǔ)到不同的地方，避免查詢時(shí)全部集中到一個(gè)實(shí)例。

其實(shí)還有一個(gè)好處，就是數(shù)據(jù)進(jìn)行主從同步時(shí)，如果 RDB 數(shù)據(jù)過(guò)大，會(huì)嚴(yán)重阻塞主線程，如果用分片的方式，可以將數(shù)據(jù)分?jǐn)?，比如原?lái)有 10 GB 的數(shù)據(jù)，分?jǐn)偤?，每個(gè)分片只有 2 GB。

可能有同學(xué)會(huì)問(wèn)，Redis 分片，和“主 - 從”模式有啥關(guān)系呢？你可以理解，圖中的每個(gè)分片都是主庫(kù)，每個(gè)分片都有自己的“主 - 從”模式結(jié)構(gòu)。

那么數(shù)據(jù)如何找到對(duì)應(yīng)的分片呢，前面其實(shí)已經(jīng)講過(guò)，假如我們有 3 臺(tái)機(jī)器，常見(jiàn)的分片方式為 hash(IP)%3，其中 3 是機(jī)器總數(shù)，hash 值為機(jī)器 IP，這樣每臺(tái)機(jī)器就有自己的分片號(hào)。

對(duì)于 key，也可以采用同樣的方式，找到對(duì)應(yīng)的機(jī)器分片號(hào) hash(key)%3，hash 算法有很多，可以用 CRC16(key)，也可以直接取 key 中的字符，通過(guò) ASCII 碼轉(zhuǎn)換成數(shù)字。

3.3 Redis 哨兵機(jī)制

3.3.1 什么是哨兵機(jī)制 ？

在主從模式下，如果 master 宕機(jī)了，從庫(kù)不能從主庫(kù)同步數(shù)據(jù)，主庫(kù)也不能提供讀寫功能。

怎么辦呢 ？這時(shí)就需要引入哨兵機(jī)制 ！

哨兵節(jié)點(diǎn)是特殊的 Redis 服務(wù)，不提供讀寫服務(wù)，主要用來(lái)監(jiān)控 Redis 實(shí)例節(jié)點(diǎn)。

那么當(dāng) master 宕機(jī)，哨兵如何執(zhí)行呢？

3.3.2 判斷主機(jī)下線

哨兵進(jìn)程會(huì)使用 PING 命令檢測(cè)它自己和主、從庫(kù)的網(wǎng)絡(luò)連接情況，用來(lái)判斷實(shí)例的狀態(tài)，如果哨兵發(fā)現(xiàn)主庫(kù)或從庫(kù)對(duì) PING 命令的響應(yīng)超時(shí)了，哨兵就會(huì)先把它標(biāo)記為“主觀下線”。

那是否一個(gè)哨兵判斷為“主觀下線”，就直接下線 master 呢？

答案肯定是不行的，需要遵循 “少數(shù)服從多數(shù)” 原則：有 N/2+1 個(gè)實(shí)例判斷主庫(kù)“主觀下線”，才判定主庫(kù)為“客觀下線”。

比如上圖有 3 個(gè)哨兵，有 2 個(gè)判斷 “主觀下線”，那么就標(biāo)記主庫(kù)為 “客觀下線”。

3.3.3 選取新主庫(kù)

我們有 5 個(gè)從庫(kù)，需要選取一個(gè)最優(yōu)的從庫(kù)作為主庫(kù)，分 2 步：

篩選：檢查從庫(kù)的當(dāng)前在線狀態(tài)和之前的網(wǎng)絡(luò)連接狀態(tài)，過(guò)濾不適合的從庫(kù)；

打分：根據(jù)從庫(kù)優(yōu)先級(jí)、和舊主庫(kù)的數(shù)據(jù)同步接近度進(jìn)行打分，選最高分作為主庫(kù)。

如果分?jǐn)?shù)一致怎么辦 ？ Redis 也有一個(gè)策略：ID 號(hào)最小的從庫(kù)得分最高，會(huì)被選為新主庫(kù)。

當(dāng) slave 3 選舉為新主庫(kù)后，會(huì)通知其它從庫(kù)和客戶端，對(duì)外宣布自己是新主庫(kù)，大家都得聽(tīng)我的哈！

今天就講這么多，我們下期見(jiàn)，大家都學(xué)廢了么 ？