這篇文章，分享自己職業(yè)生涯經(jīng)歷的五種 Redis 部署模式，希望對(duì)大家有所啟發(fā)。

1.單實(shí)例

這是 Redis 最簡(jiǎn)單、最基礎(chǔ)的部署方式，即：整個(gè) Redis 服務(wù)運(yùn)行在單個(gè)服務(wù)器和單個(gè)進(jìn)程中。

筆者第一次在生產(chǎn)環(huán)境使用 Redis ，是在藝龍紅包系統(tǒng)中，使用 Redis 實(shí)現(xiàn)分布式鎖。

圖片

因?yàn)樯暇€(xiàn)時(shí)間要求比較著急，運(yùn)維說(shuō)有一個(gè)實(shí)例可以不用申請(qǐng)，可以直接用，于是就采用了單實(shí)例的模式。筆者還特意和運(yùn)維說(shuō)假如 Redis 掛了，就通過(guò)  Linux 定時(shí)任務(wù)重新啟動(dòng) 。

單實(shí)例模式的優(yōu)點(diǎn)顯而易見(jiàn)：簡(jiǎn)單（部署、配置、維護(hù)），但缺點(diǎn)同樣突出：服務(wù)器宕機(jī)，服務(wù)將完全不可用，同時(shí)內(nèi)存大小受限于服務(wù)器。

2.主從 + 哨兵

在藝龍紅包系統(tǒng)初版上線(xiàn)后，團(tuán)隊(duì)架構(gòu)師向我介紹了Redis的高可用方案——主從復(fù)制+哨兵集群模式。這種部署模式通過(guò)主從數(shù)據(jù)同步實(shí)現(xiàn)數(shù)據(jù)備份，配合哨兵集群的自動(dòng)故障檢測(cè)與主從切換能力，能夠有效保障服務(wù)的高可用性。

如圖所示的架構(gòu)中：

圖片

• 主節(jié)點(diǎn)負(fù)責(zé)處理所有寫(xiě)請(qǐng)求
• 從節(jié)點(diǎn)實(shí)時(shí)同步主節(jié)點(diǎn)數(shù)據(jù)，可分擔(dān)讀請(qǐng)求
• 哨兵集群持續(xù)監(jiān)控節(jié)點(diǎn)健康狀態(tài)
• 當(dāng)主節(jié)點(diǎn)故障時(shí)，哨兵會(huì)自動(dòng)選舉新的主節(jié)點(diǎn)

通過(guò)這種改造，紅包系統(tǒng)的緩存架構(gòu)獲得了質(zhì)的提升：不僅避免了單點(diǎn)故障風(fēng)險(xiǎn)，還實(shí)現(xiàn)了讀寫(xiě)分離，整體系統(tǒng)的穩(wěn)定性和可用性都得到了顯著增強(qiáng)。即便在突發(fā)故障情況下，也能保證紅包業(yè)務(wù)持續(xù)穩(wěn)定運(yùn)行。

3.分片集群 + 一致性 Hash

「主從 + 哨兵」模式非常健壯，但假如緩存數(shù)據(jù)量非常大，這種模式就有瓶頸了，于是需要多組 Redis 實(shí)例才能滿(mǎn)足業(yè)務(wù)需求。

藝龍的流式計(jì)算服務(wù)的計(jì)算過(guò)程大量依賴(lài)存這種多 Redis 實(shí)例模式 ，如下圖：

圖片

我們可以采用一致性哈希算法實(shí)現(xiàn)數(shù)據(jù)分片：

圖片

• 哈希環(huán)構(gòu)建：將整個(gè)哈希空間（0~2^32-1）組織成環(huán)形結(jié)構(gòu) 。
• 節(jié)點(diǎn)映射：對(duì)每個(gè)Redis節(jié)點(diǎn)計(jì)算多個(gè)虛擬節(jié)點(diǎn)（通常200-300個(gè)）的哈希值，均勻分布在環(huán)上 。
• 數(shù)據(jù)路由：對(duì)每個(gè)key計(jì)算哈希值，在環(huán)上順時(shí)針找到最近的節(jié)點(diǎn) 。

流式計(jì)算的 Redis 集群都僅僅采用單主集群模式，存在一定的高可用風(fēng)險(xiǎn)，比如某個(gè)分片掛掉了，整個(gè)系統(tǒng)就會(huì)出現(xiàn)問(wèn)題。

解決方案其實(shí)也很簡(jiǎn)單：

• 每個(gè)分片都是主從模式
• 哨兵集群監(jiān)控(自動(dòng)切換主從)

架構(gòu)圖就變成下圖的緩存部署架構(gòu)（神州專(zhuān)車(chē)訂單緩存部署架構(gòu)）：

圖片

4.分片集群 + 預(yù)分配

當(dāng)我們?cè)賮?lái)看「分片集群 + 一致性 Hash」 這種模式時(shí)，雖然看起來(lái)很完美，但是有一個(gè)隱形的缺點(diǎn)：

當(dāng)新增分片時(shí)，如何做到數(shù)據(jù)可以平滑遷移到新的分片節(jié)點(diǎn) ？

解決這種問(wèn)題最有效的方案是：預(yù)分配槽位 。

筆者曾經(jīng)介紹過(guò)專(zhuān)車(chē)的分庫(kù)分表算法，假設(shè)現(xiàn)在需要將訂單表平均拆分到 4 個(gè)分庫(kù) shard0 ，shard1 ，shard2 ，shard3 。

首先將 [0-1023] 平均分為4個(gè)區(qū)段：[0-255]，[256-511]，[512-767]，[768-1023]，然后對(duì)字符串（或子串，由用戶(hù)自定義）做 hash， hash 結(jié)果對(duì) 1024 取模，最終得出的結(jié)果 slot 落入哪個(gè)區(qū)段，便路由到哪個(gè)分庫(kù)。

圖片

我們可以將分庫(kù)分表的預(yù)分配理論應(yīng)用到 Redis 分片集群中，見(jiàn)下圖：

圖片

大名鼎鼎的開(kāi)源項(xiàng)目 Codis 也是使用預(yù)分配的技巧，「分片集群 + 預(yù)分配」既可以保留分片集群的可擴(kuò)展的優(yōu)勢(shì)，也可以通過(guò)預(yù)分配槽位的技巧實(shí)現(xiàn)較為平滑的數(shù)據(jù)遷移，但數(shù)據(jù)遷移還是非?？简?yàn)架構(gòu)師的功底。

有沒(méi)有一種方案可以支持所有的特性呢 ？

有的，它來(lái)了，它就是：官方 Redis Cluster 。

5.官方 Redis Cluster

筆者在花生好車(chē)和科大訊飛都使用過(guò) Redis Cluster 這種模式。

1

Redis Cluster 集群具有如下幾個(gè)特點(diǎn)：

• 集群完全去中心化，采用多主多從；
• 每一個(gè)分區(qū)都是由一個(gè)Redis主機(jī)和多個(gè)從機(jī)組成，分片和分片之間是相互平行的。
• Redis Cluster 無(wú)需部署哨兵集群，集群內(nèi) Redis 節(jié)點(diǎn)通過(guò) Gossip 協(xié)議互相探測(cè)健康狀態(tài)，在故障時(shí)可發(fā)起自動(dòng)切換。
• Redis Cluster將數(shù)據(jù)分為16384個(gè)槽位，每個(gè)節(jié)點(diǎn)負(fù)責(zé)管理一部分槽位。
• 當(dāng)客戶(hù)端向 Redis Cluster 發(fā)送請(qǐng)求時(shí)，Cluster 會(huì)根據(jù)鍵的哈希值將請(qǐng)求路由到相應(yīng)的節(jié)點(diǎn)。具體來(lái)說(shuō)，Redis Cluste r使用 CRC16 算法計(jì)算鍵的哈希值，然后對(duì)16384 取模，得到槽位編號(hào)。
• Redis Cluster 提供了「配套」的 SDK，只要客戶(hù)端升級(jí) SDK，就可以和 Redis Cluster 集成，SDK 會(huì)幫你找到 key 對(duì)應(yīng)的 Redis 節(jié)點(diǎn)進(jìn)行讀寫(xiě)，還能自動(dòng)適配 Redis 節(jié)點(diǎn)的增加和刪除，業(yè)務(wù)側(cè)無(wú)感知。

Redis Cluster 從功能來(lái)講，已經(jīng)趨近于完美，在提供高可用性的同時(shí)，實(shí)現(xiàn)了數(shù)據(jù)分片和負(fù)載均衡，適用于大規(guī)模數(shù)據(jù)存儲(chǔ)和高性能要求的場(chǎng)景。但是配置和運(yùn)維相對(duì)復(fù)雜，以及一些復(fù)雜的多鍵操作可能受到限制。

6.真的有銀彈嗎

在 Redis 的部署模式演進(jìn)過(guò)程中，從單實(shí)例到 Redis Cluster，我們看到了不同架構(gòu)的優(yōu)缺點(diǎn)。

但沒(méi)有一種方案是完美的銀彈，每種模式都有其適用場(chǎng)景和局限性。

圖片

所以，我們需要理解業(yè)務(wù)需求，權(quán)衡性能、擴(kuò)展性和運(yùn)維成本，才能做出最佳的選擇。