面試官：Redis 有哪些拓展方案？

前言

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

作為最廣泛使用的KV記憶體資料庫之一，在當今的大流量時代，單機模式略顯單薄，免不了要有一些拓展的方案。為最廣泛使用的KV記憶體資料庫之一，在當今的大流量時代，單機模式略顯單薄，免不了要有一些拓展的方案。

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

正文

先從基礎的拓展方式開始，這樣更便于了解較進階的模式。

分區

概述

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

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

或者假設手中有N台機器可以作為Redis伺服器

所有機器記憶體總和有256G, 而用戶端正好也需要一個大記憶體的存儲空間。

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

單指分區來講，即将全部資料分散在多個Redis執行個體中，每個執行個體不需要關聯，可以是完全獨立的。

使用方式

用戶端處理

和傳統的資料庫分庫分表一樣，可以從key入手，先進行計算，找到對應資料存儲的執行個體在進行操作。

範圍角度，比如orderId:1orderId:1000放入執行個體1，orderId:1001orderId:2000放入執行個體2...

哈希計算，就像我們的hashmap一樣，用hash函數加上位運算或者取模，進階玩法還有一緻性Hash等操作，找到對應的執行個體進行操作

使用代理中間件

我們可以開發獨立的代理中間件，屏蔽掉處理資料分片的邏輯，獨立運作。

當然也有他人已經造好的輪子，Redis也有優秀的代理中間件，譬如Twemproxy，或者codis，可以結合場景選擇是否使用。

缺點

無緣多key操作，key都不一定在一個執行個體上，那麼多key操作或者多key事務自然是不支援。

維護成本，由于每個執行個體在實體和邏輯上，都屬于單獨的一個節點，缺乏統一管理。

靈活性有限，範圍分片還好，比如hash+MOD這種方式，如果想動态調整Redis執行個體的數量，就要考慮大量資料遷移，這就非常麻煩了。

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

主從

概述資料遷移

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

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

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

主從就是另一個緯度的拓展，節點将資料同步到從節點，就像将執行個體“分身”了一樣，可靠性又提高了不少。

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

有了“執行個體分身”，自然就可以做讀寫分離，将讀流量均攤在各個從節點。

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

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

作為主節點的Redis執行個體，并不要求配置任何參數，隻需要正常啟動

作為從節點的執行個體，使用配置檔案或指令方式REPLICAOF 主節點Host 主節點port即可完成主從配置

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

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

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

slave節點都是隻讀的，如果寫流量大的場景，就有些力不從心了。 那我把slave節點隻讀關掉不就行了？當然不行，資料複制是由主到從，從節點獨有資料同步不到主節點，資料就不一緻了。

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

哨兵

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

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

并且還能夠充當配置提供者，提供主節點的資訊，就算發生了故障轉移，也能提供正确的位址。

哨兵本身也是Redis執行個體的一種，但不作為資料存儲方使用，啟動指令也是不一樣的。

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

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