如何用3臺機器輕鬆搭建一個高可用Redis服務架構？

基於記憶體的 Redis 應該是目前各種 Web 開發業務中最為常用的 key-value 資料庫了。

我們經常在業務中用其儲存使用者登陸態（Session 儲存），加速一些熱資料的查詢（相比較 MySQL 而言，速度有數量級的提升），做簡單的訊息佇列（LPUSH 和 BRPOP）、訂閱釋出（PUB/SUB）系統等等。

規模比較大的網際網路公司，一般都會有專門的團隊，將 Redis 儲存以基礎服務的形式提供給各個業務呼叫。

不過任何一個基礎服務的提供方，都會被呼叫方問起的一個問題是：你的服務是否具有高可用性？最好不要因為你的服務經常出問題，導致我這邊的業務跟著遭殃。

最近在我的專案中自己搭了一套小型的“高可用”Redis 服務，在此做一下自己的總結和思考。

首先我們要定義一下對於 Redis 服務來說怎樣才算是高可用，即在各種出現異常的情況下，依然可以正常提供服務；或者寬鬆一些，出現異常的情況下，只經過很短暫的時間即可恢復正常服務。

所謂異常，應該至少包含了以下三種可能性：

• 某個節點伺服器的某個程式突然 down 掉，例如某開發手殘，把一臺伺服器的 redis-server 程式 kill 了。

• 某臺節點伺服器 down 掉，相當於這個節點上所有程式都停了，例如某運維手殘，把一個伺服器的電源拔了；例如一些老舊機器出現硬體故障。

• 任意兩個節點伺服器之間的通訊中斷了，例如某臨時工手殘，把用於兩個機房通訊的光纜挖斷了。

其實以上任意一種異常都是小概率事件，而做到高可用性的基本指導思想就是：多個小概率事件同時發生的概率可以忽略不計，只要我們設計的系統可以容忍短時間內的單點故障，即可實現高可用性。

對於搭建高可用 Redis 服務，網上已有了很多方案，例如 Keepalived、Codis、Twemproxy、Redis Sentinel。

其中 Codis 和 Twemproxy 主要是用於大規模的 Redis 叢集中，也是在 Redis 官方釋出 Redis Sentinel 之前 Twitter 和豌豆莢提供的開源解決方案。

我的業務中資料量並不大，所以搞叢集服務反而是浪費機器了。最終在 Keepalived 和 Redis Sentinel 之間做了個選擇，選擇了官方的解決方案 Redis Sentinel。

Redis Sentinel 可以理解為一個監控 Redis Server 服務是否正常的程式，並且一旦檢測到不正常，可以自動地將備份（slave）Redis Server 啟用，使得外部使用者對 Redis 服務內部出現的異常無感知。

下面我們按照由簡至繁的步驟，搭建一個最小型的高可用的 Redis 服務。

方案1：單機版 Redis Server，無 Sentinel

一般情況下，我們搭的個人網站或者平時做開發時，會起一個單例項的 Redis Server。

呼叫方直接連線 Redis 服務即可，甚至 Client 和 Redis 本身就處於同一臺伺服器上。

這種搭配僅適合個人學習娛樂，畢竟這種配置總會有單點故障的問題無法解決。

一旦 Redis 服務程式掛了，或者伺服器 1 停機了，那麼服務就不可用了。並且如果沒有配置 Redis 資料持久化的話，Redis 內部已經儲存的資料也會丟失。

方案2：主從同步 Redis Server，單例項 Sentinel

為了實現高可用，解決方案 1 中所述的單點故障問題，我們必須增加一個備份服務，即在兩臺伺服器上分別啟動一個 Redis Server 程式，一般情況下由 master 提供服務，slave 只負責同步和備份。

與此同時，在額外啟動一個 Sentinel 程式，監控兩個 Redis Server 例項的可用性，以便在 master 掛掉的時候，及時把 slave 提升到 master 的角色繼續提供服務，這樣就實現了 Redis Server 的高可用。

這基於一個高可用服務設計的依據，即單點故障本身就是個小概率事件，而多個單點同時故障（即 master 和 slave 同時掛掉），可以認為是（基本）不可能發生的事件。

對於 Redis 服務的呼叫方來說，現在要連線的是 Redis Sentinel 服務，而不是 Redis Server 了。

常見的呼叫過程是，client 先連線 Redis Sentinel 並詢問目前 Redis Server 中哪個服務是 master，哪些是 slave，然後再去連線相應的 Redis Server 進行操作。

當然目前的第三方庫一般都已經實現了這一呼叫過程，不再需要我們手動去實現（例如 Nodejs 的 ioredis，PHP 的 predis，Golang 的 go-redis/redis，Java 的 jedis 等）。

然而，我們實現了 Redis Server 服務的主從切換之後，又引入了一個新的問題，即 Redis Sentinel 本身也是個單點服務，一旦 Sentinel 程式掛了，那麼客戶端就沒辦法連結 Sentinel 了。所以說，方案 2 的配置無法實現高可用性。

方案3：主從同步 Redis Server，雙例項 Sentinel

為了解決方案 2 的問題，我們把 Redis Sentinel 程式也額外啟動一份，兩個 Sentinel 程式同時為客戶端提供服務發現的功能。

對於客戶端來說，它可以連線任何一個 Redis Sentinel 服務，來獲取當前 Redis Server 例項的基本資訊。

通常情況下，我們會在 Client 端配置多個 Redis Sentinel 的連結地址，Client 一旦發現某個地址連線不上，會去試圖連線其他的 Sentinel 例項。

這當然也不需要我們手動實現，各個開發語言中比較熱門的 Redis 連線庫都幫我們實現了這個功能。

我們預期是：即使其中一個 Redis Sentinel 掛掉了，還有另外一個 Sentinel 可以提供服務。

然而，願景是美好的，現實卻是很殘酷的。如此架構下，依然無法實現 Redis 服務的高可用。

方案 3 示意圖中，紅線部分是兩臺伺服器之間的通訊，而我們所設想的異常場景（異常2）是：某臺伺服器整體當機，不妨假設伺服器 1 停機，此時，只剩下伺服器 2 上面的 Redis Sentinel 和 slave Redis Server 程式。

這時，Sentinel 其實是不會將僅剩的 slave 切換成 master 繼續服務的，也就導致 Redis 服務不可用，因為 Redis 的設定是隻有當超過 50% 的 Sentinel 程式可以連通並投票選取新的 master 時，才會真正發生主從切換。

本例中兩個 Sentinel 只有一個可以連通，等於 50% 並不在可以主從切換的場景中。

你可能會問，為什麼 Redis 要有這個 50% 的設定？假設我們允許小於等於 50% 的 Sentinel 連通的場景下也可以進行主從切換呢？

試想一下異常 3，即伺服器 1 和伺服器 2 之間的網路中斷，但是伺服器本身是可以執行的，如下圖所示：

實際上對於伺服器 2 來說，伺服器 1 直接當機和伺服器 1 網路連不通是一樣的效果，都是突然就無法進行任何通訊了。

假設網路中斷時我們允許伺服器 2 的 Sentinel 把 slave 切換為 master，結果就是你現在擁有了兩個可以對外提供服務的 Redis Server。

Client 做任何的增刪改操作，有可能落在伺服器 1 的 Redis 上，也有可能落在伺服器 2 的 Redis 上（取決於 Client 到底連通的是哪個 Sentinel），造成資料混亂。

即使後面伺服器1和伺服器2之間的網路又恢復了，我們也無法把資料統一了（兩份不一樣的資料，到底該信任誰呢？），資料一致性完全被破壞。

 

方案4：主從同步 Redis Server，三例項 Sentinel

鑑於方案 3 並沒有辦法做到高可用，我們最終的版本就是上圖所示的方案 4 了，實際上這就是我們最終搭建的架構。

我們引入了伺服器 3，並且在 3 上面又搭建起一個 Redis Sentinel 程式，現在由三個 Sentinel 程式來管理兩個 Redis Server 例項。

這種場景下，不管是單一程式故障、還是單個機器故障、還是某兩個機器網路通訊故障，都可以繼續對外提供 Redis 服務。

實際上，如果你的機器比較空閒，當然也可以把伺服器 3 上面也開啟一個 Redis Server，形成 1 master + 2 slave 的架構。

每個資料都有兩個備份，可用性會提升一些。當然也並不是 slave 越多越好，畢竟主從同步也是需要時間成本的。

在方案 4 中，一旦伺服器 1 和其他伺服器的通訊完全中斷，那麼伺服器 2 和 3 會將 slave 切換為 master。

對於客戶端來說，在這麼一瞬間會有 2 個 master 提供服務，並且一旦網路恢復了，那麼所有在中斷期間落在伺服器 1 上的新資料都會丟失。

如果想要部分解決這個問題，可以配置 Redis Server 程式，讓其在檢測到自己網路有問題的時候，立即停止服務，避免在網路故障期間還有新資料進來（可以參考 Redis 的 min-slaves-to-write 和 min-slaves-max-lag 這兩個配置項）。

至此，我們就用 3 臺機器搭建了一個高可用的 Redis 服務。其實網上還有更加節省機器的辦法，就是把一個 Sentinel 程式放在 Client 機器上，而不是服務提供方的機器上。

只不過在公司裡面，一般服務的提供方和呼叫方並不來自同一個團隊。兩個團隊共同操作同一個機器，很容易因為溝通問題導致一些誤操作，所以出於這種人為因素的考慮，我們還是採用了方案 4 的架構。

並且由於伺服器 3 上面只跑了一個 Sentinel 程式，對伺服器資源消耗並不多，還可以用伺服器 3 來跑一些其他的服務。

易用性：像使用單機版 Redis 一樣使用 Redis Sentinel

作為服務的提供方，我們總是會講到使用者體驗問題。在上述方案當中始終有一個讓 Client 端用的不是那麼舒服的地方。

對於單機版 Redis，Client 端直接連線 Redis Server，我們只需要給一個 ip 和 port，Client 就可以使用我們的服務了。

而改造成 Sentinel 模式之後，Client 不得不採用一些支援 Sentinel 模式的外部依賴包，並且還要修改自己的 Redis 連線配置，這對於“矯情”的使用者來講顯然是不能接收的。

有沒有辦法還是像在使用單機版的 Redis 那樣，只給 Client 一個固定的 ip 和 port 就可以提供服務呢？

答案當然是肯定的。這可能就要引入虛擬 IP（Virtual IP，VIP），如上圖所示。

我們可以把虛擬 IP 指向 Redis Server master 所在的伺服器，在發生 Redis 主從切換的時候，會觸發一個回撥指令碼，回撥指令碼中將 VIP 切換至 slave 所在的伺服器。

這樣對於 Client 端來說，他彷彿在使用的依然是一個單機版的高可用 Redis 服務。

結語

搭建任何一個服務，做到“能用”其實是非常簡單的，就像我們執行一個單機版的 Redis。

不過一旦要做到“高可用”，事情就會變得複雜起來。業務中使用了額外的兩臺伺服器，3 個 Sentinel 程式+1 個 Slave 程式，只是為了保證在那小概率的事故中依然做到服務可用。

在實際業務中我們還啟用了 supervisor 做程式監控，一旦程式意外退出，會自動嘗試重新啟動。