解析高可用Redis服務架構分析與搭建方案

Posted on by

基於內存的Redis應該是目前各種web開發業務中最為常用的key-value數據庫瞭，我們經常在業務中用其存儲用戶登陸態（Session存儲），加速一些熱數據的查詢（相比較mysql而言，速度有數量級的提升），做簡單的消息隊列（LPUSH和BRPOP）、訂閱發佈（PUB/SUB）系統等等。規模比較大的互聯網公司，一般都會有專門的團隊，將Redis存儲以基礎服務的形式提供給各個業務調用。

不過任何一個基礎服務的提供方，都會被調用方問起的一個問題是：你的服務是否具有高可用性？最好不要因為你的服務經常出問題，導致我這邊的業務跟著遭殃。最近我所在的項目中也自己搭瞭一套小型的“高可用”Redis服務，在此做一下自己的總結和思考。

首先我們要定義一下對於Redis服務來說怎樣才算是高可用，即在各種出現異常的情況下，依然可以正常提供服務。或者寬松一些，出現異常的情況下，隻經過很短暫的時間即可恢復正常服務。所謂異常，應該至少包含瞭以下幾種可能性：

【異常1】某個節點服務器的某個進程突然down掉（例如某開發手殘，把一臺服務器的redis-server進程kill瞭）

【異常2】某臺節點服務器down掉，相當於這個節點上所有進程都停瞭（例如某運維手殘，把一個服務器的電源拔瞭；例如一些老舊機器出現硬件故障）

【異常3】任意兩個節點服務器之間的通信中斷瞭（例如某臨時工手殘，把用於兩個機房通信的光纜挖斷瞭）

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

對於搭建高可用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】）是，某臺服務器整體down機，不妨假設服務器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直接down掉和服務器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做進程監控，一旦進程意外退出，會自動嘗試重新啟動。

以上就是高可用Redis服務架構分析與搭建的詳細內容，更多關於高可用Redis服務架構的資料請關註WalkonNet其它相關文章！

推薦閱讀：