| 前言

Redis 大家都不陌生，就算是沒用過，也都聽說過了。

作爲最廣泛使用的 KV 內存數據庫之一，在當今的大流量時代，單機模式略顯單薄，免不了要有一些拓展的方案。

筆者下文會對各種方案進行介紹，並且給出_場景_，_實現_ 等等概述，還會提到一些新手常見的誤區。

| 正文

先從基礎的拓展方式開始，這樣更便於理解較高級的模式。

ps: 本文背景是以筆者落筆時官網最新穩定版 5.0.8 爲準，雖然還沒寫完就變成了 6.0.1。

分區

> 概述

分區 (Partitioning) 是一種最爲簡單的拓展方式。

在我們面臨單機的存儲空間瓶頸時，第一點就能想到像傳統的關係型數據庫一樣，進行數據分區。

或者假設手中有 N 臺機器可以作爲 Redis 服務器，所有機器內存總和有 256G, 而客戶端正好也需要一個大內存的存儲空間。

我們除了可以把內存條都拆下來焊到一個機器上，也可以選擇分區使用，這樣又拓展了計算能力。

單指分區來講，即將全部數據分散在多個 Redis 實例中，每個實例不需要關聯，可以是完全獨立的。

> 使用方式

• 客戶端處理
  和傳統的數據庫分庫分表一樣，可以從 key 入手，先進行計算，找到對應數據存儲的實例在進行操作。範圍角度，比如 orderId:1~orderId:1000 放入實例 1，orderId:1001~orderId:2000 放入實例 2。
  哈希計算，就像我們的 hashmap 一樣，用 hash 函數加上位運算或者取模，高級玩法還有一致性 Hash 等操作，找到對應的實例進行操作

• 使用代理中間件
  我們可以開發獨立的代理中間件，屏蔽掉處理數據分片的邏輯，獨立運行。
  當然也有他人已經造好的輪子，Redis 也有優秀的代理中間件，譬如 Twemproxy，或者 codis，可以結合場景選擇是否使用。

> 缺點

• 無緣多 key 操作，key 都不一定在一個實例上，那麼多 key 操作或者多 key 事務自然是不支持。

• 維護成本，由於每個實例在物理和邏輯上，都屬於單獨的一個節點，缺乏統一管理。

• 靈活性有限，範圍分片還好，比如 hash+MOD 這種方式，如果想動態調整 Redis 實例的數量，就要考慮大量數據遷移，這就非常麻煩了。

同爲開發者，深知我們雖然總能 “曲線救國” 的完成一些當前環境不支持的功能，但是總歸要麻煩一些。

主從

> 概述數據遷移

常說的主從 (Master-Slave)，也就是複製 (Replication) 方式，怎麼稱呼都可以。

同上面的分區一樣，也是 Redis 高可用架構的基礎，新手可能會誤以爲這類基礎模式即是 “高可用”，這並不是十分正確的。

分區暫時能解決單點無法容納的數據量問題，但是一個 Key 還是隻在一個實例上，在大流量時代顯得不那麼可靠。

主從就是另一個緯度的拓展，節點將數據同步到從節點，就像將實例 “分身” 了一樣，可靠性又提高了不少。

圖畫的有些誇張了，主要還是想體現結構靈活，是一主一從，還是一主多從，還是一主多從多從... 看你心情

有了 “實例分身”，自然就可以做讀寫分離，將讀流量均攤在各個從節點。

> 使用方式

高手雲集的時代，聊天軟件難免要備上這麼一張表情包。

這表情包和使用方式有什麼關係呢？首先看看使用方式：

1. 作爲主節點的 Redis 實例，並不要求配置任何參數，只需要正常啓動

2. 作爲從節點的實例，使用配置文件或命令方式REPLICAOF 主節點Host 主節點port即可完成主從配置

是不是和表情包一樣，“dalao” 沒動，我去 “抱大腿”。

這樣一個主從最小配置就完成了，主從實例即可對外提供服務。

命令裏的 “主節點” 是相對的，slave 也可以抱 slave 大腿，也就是上文提到的結構靈活。

> 缺點

• slave 節點都是只讀的，如果寫流量大的場景，就有些力不從心了。
  那我把 slave 節點只讀關掉不就行了？當然不行，數據複製是由主到從，從節點獨有數據同步不到主節點，數據就不一致了。

• 故障轉移不友好，主節點掛掉後，寫處理就無處安放，需要手工的設定新的主節點，如使用REPLICAOF no one(誰大腿我都不抱了) 晉升爲主節點，再梳理其他 slave 節點的新主配置，相對來說比較麻煩。

哨兵

> 概述

主從的手工故障轉移，肯定讓人很難接受，自然就出現了高可用方案 - 哨兵（Sentinel）。

我們可以在主從架構不變的場景，直接加入 Redis Sentinel，對節點進行監控，來完成自動的故障發現與轉移。

並且還能夠充當配置提供者，提供主節點的信息，就算髮生了故障轉移，也能提供正確的地址。

哨兵本身也是 Redis 實例的一種，但不作爲數據存儲方使用，啓動命令也是不一樣的。

雖然圖有些複雜，看起來像要召喚光能使者。

其實實際使用起來是很便捷的。

> 使用方式

Sentinel 的最小配置，一行即可：

1sentinel monitor <主節點別名> <主節點host> <主節點端口> <票數>

只需要配置master即可，然後用
redis-sentinel <配置文件>
redis-sentinel <配置文件>
 命令即可啓用。

Redis 官網提到的 “最小配置” 是如下所示，除了上面提到的一行，還有其它的一些配置：

1sentinel monitor mymaster 127.0.0.1 6379 2
2sentinel down-after-milliseconds mymaster 60000
3sentinel failover-timeout mymaster 180000
4sentinel parallel-syncs mymaster 1
5
6sentinel monitor resque 192.168.1.3 6380 4
7sentinel down-after-milliseconds resque 10000
8sentinel failover-timeout resque 180000
9sentinel parallel-syncs resque 5

正如該例所示，設置主節點別名就是爲了監控多主的時候，與其額外配置項能夠與其對應, 以及 sentinel 一些命令，如SENTINEL get-master-addr-by-name就要用到別名了。

哨兵數量建議在三個以上且爲奇數，在 Redis 官網也提到了各種情況的 “佈陣” 方式，非常值得參考。

> 更多

既然是高可用方案，並非有嚴格意義上的 “缺點”，還需配合使用場景進行考量。

• 故障轉移期間短暫的不可用，但其實官網的例子也給出了parallel-syncs參數來指定並行的同步實例數量，以免全部實例都在同步出現整體不可用的情況，相對來說要比手工的故障轉移更加方便。

• 分區邏輯需要自定義處理，雖然解決了主從下的高可用問題，但是 Sentinel 並沒有提供分區解決方案，還需開發者考慮如何建設。

• 既然是還是主從，如果異常的寫流量搞垮了主節點，那麼自動的 “故障轉移” 會不會變成自動“災難傳遞”，即 slave 提升爲 Master 之後掛掉，又進行提升又被掛掉。

      不過最後這點也是筆者猜測，並沒有聽說過出現這種案例，可不必深究。

集羣

> 概述

Redis Cluster 是官方在 3.0 版本後推出的分佈式方案。

對開發者而言，“官方支持” 一詞是大概率非常美好的，小到 issue，大到 feature。自定義去解決問題，成本總是要高一些。

有了官方的正式集羣方案，從請求路由、故障轉移、彈性伸縮幾個緯度的使用上，將更爲容易。

Cluster 不同於哨兵，是支持分區的。有說法 Cluster 是哨兵的升級，這是不嚴謹的。

二者緯度不一樣，如果因爲 Cluster 也有故障轉移的功能，就說它是哨兵的升級款，略顯牽強。

Cluster 在分區管理上，使用了 “哈希槽”(hash slot) 這麼一個概念，一共有 16384 個槽位，每個實例負責一部分槽，通過CRC16（key）&16383這樣的公式，計算出來 key 所對應的槽位。

雖然在節點和 key 二者中又引入了槽的概念，看起來不易理解，實際上因爲顆粒度更細了，減少了節點的擴容和收縮難度，相比傳統策略還是很有優勢。

當然，“槽”是虛擬的概念，節點自身去維護 “槽” 的關係，並不是要真正下載啓動個 “槽服務” 在跑。

> 使用方式

Redis 的各種玩法，都是從配置文件着手，集羣也不例外。

1cluster-enabled yes
2cluster-config-file "redis-node.conf"

• 開啓集羣

• 指定集羣配置文件

集羣配置文件 (cluster-config-file) 爲內部使用，可以不去指定，Redis 會幫助創建一個。啓動還是普通的方式redis-server redis.conf

首先以集羣方式啓動了 N 臺 Redis 實例，這當然還沒完事。

接下來的步驟筆者稱爲 “牽線搭橋分配槽”，聽起來還算順口。

“牽線搭橋分配槽” 的方式也在不斷升級，從直接用原始命令來處理，到使用腳本，以及現在的 Redis-cli 官方支持，使用哪種方式都可以。

1redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 \
2127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
3--cluster-replicas 1

這樣集羣就搭建完成了，當然，使用官方提供的 check 命令檢查一下，也是有必要的。

1redis-cli --cluster check 127.0.0.1:7001

• 雖然是對分區良好支持，但也有一些分區的老問題，譬如：如果不在同一個 “槽” 的數據，是沒法使用類似 mset 的多鍵操作。

• 在 select 命令頁有提到, 集羣模式下只能使用一個庫，雖然平時一般也是這麼用的，但是要了解一下。

• 運維上也要謹慎，俗話說得好，“使用越簡單底層越複雜”，啓動搭建是很方便，使用時面對帶寬消耗，數據傾斜等等具體問題時，還需人工介入，或者研究合適的配置參數。

| 結尾

趣談

在寫 “主從” 方案的時候，發現有一個有趣的事情：

筆者開始是記得主從的關鍵命令是SLAVEOF，後來查閱官方的時候，發現命令已經更改爲REPLICAOF，雖然SLAVEOF還能用。

官網的一些描述詞彙，有的地方還是 Slave，也有些是用 Replication。

好奇的筆者查了一下相關的資料，並看了些 Redis 作者 antirez 的有關此時博客，發現已經是兩年前的事情了。

其實就是 “Slave” 這個變量名給了一些人機會，藉此 “噴” 了一波作者，作者也做出了一部分妥協。

有興趣的盆友可以自己搜搜看，技術外的東西就不做評價了，看個樂呵就行。

筆者的主要目的還是：看官方文檔的時候，別讓不同的 “詞彙” 迷惑了。

END

本文對 Redis 這些拓展方案都作出了大致描述。

具體使用上，還需留意詳細配置，以及客戶端支持等綜合情況來考量。

作者：Vt

來源：https://juejin.cn/post/6844904147943161869

****關注架構師 (JiaGouX)，添加 “星標”

獲取每天技術乾貨，一起成爲牛逼架構師

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/KSOMPM5N-LfUbUqoQiUBXA