基于內(nèi)存的Redis應(yīng)該是目前各種web開發(fā)業(yè)務(wù)中最為常用的key-value數(shù)據(jù)庫了，我們經(jīng)常在業(yè)務(wù)中用其存儲用戶登陸態(tài)(Session存儲)，加速一些熱數(shù)據(jù)的查詢(相比較mysql而言，速度有數(shù)量級的提升)，做簡單的消息隊列(LPUSH和BRPOP)、訂閱發(fā)布(PUB/SUB)系統(tǒng)等等。規(guī)模比較大的互聯(lián)網(wǎng)公司，一般都會有專門的團隊，將Redis存儲以基礎(chǔ)服務(wù)的形式提供給各個業(yè)務(wù)調(diào)用。

[[266506]]

不過任何一個基礎(chǔ)服務(wù)的提供方，都會被調(diào)用方問起的一個問題是：你的服務(wù)是否具有高可用性?***不要因為你的服務(wù)經(jīng)常出問題，導(dǎo)致我這邊的業(yè)務(wù)跟著遭殃。最近在項目中也搭了一套小型的“高可用”Redis服務(wù)，在此做一下自己的總結(jié)和思考。

首先要定義一下對于Redis服務(wù)來說怎樣才算是高可用，即在各種出現(xiàn)異常的情況下，依然可以正常提供服務(wù)。或者寬松一些，出現(xiàn)異常的情況下，只經(jīng)過很短暫的時間即可恢復(fù)正常服務(wù)。所謂異常，應(yīng)該至少包含了以下幾種可能性：

【異常1】某個節(jié)點服務(wù)器的某個進程突然down掉(例如某開發(fā)手殘，把一臺服務(wù)器的redis-server進程kill了)

【異常2】某臺節(jié)點服務(wù)器down掉，相當(dāng)于這個節(jié)點上所有進程都停了(例如某運維手殘，把一個服務(wù)器的電源拔了;例如一些老舊機器出現(xiàn)硬件故障)

【異常3】任意兩個節(jié)點服務(wù)器之間的通信中斷了(例如某臨時工手殘，把用于兩個機房通信的光纜挖斷了)

其實以上任意一種異常都是小概率事件，而做到高可用性的基本指導(dǎo)思想就是：多個小概率事件同時發(fā)生的概率可以忽略不計。只要我們設(shè)計的系統(tǒng)可以容忍短時間內(nèi)的單點故障，即可實現(xiàn)高可用性。

對于搭建高可用Redis服務(wù)，網(wǎng)上已有了很多方案，例如Keepalived，Codis，Twemproxy，Redis Sentinel。其中Codis和Twemproxy主要是用于大規(guī)模的Redis集群中，也是在Redis官方發(fā)布Redis Sentinel之前twitter和豌豆莢提供的開源解決方案。我的業(yè)務(wù)中數(shù)據(jù)量并不大，所以搞集群服務(wù)反而是浪費機器了。最終在Keepalived和Redis Sentinel之間做了個選擇，選擇了官方的解決方案Redis Sentinel。

Redis Sentinel可以理解為一個監(jiān)控Redis Server服務(wù)是否正常的進程，并且一旦檢測到不正常，可以自動地將備份(slave)Redis Server啟用，使得外部用戶對Redis服務(wù)內(nèi)部出現(xiàn)的異常無感知。我們按照由簡至繁的步驟，搭建一個最小型的高可用的Redis服務(wù)。

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

一般情況下，我們搭的個人網(wǎng)站，或者平時做開發(fā)時，會起一個單實例的Redis Server。調(diào)用方直接連接Redis服務(wù)即可，甚至Client和Redis本身就處于同一臺服務(wù)器上。這種搭配僅適合個人學(xué)習(xí)娛樂，畢竟這種配置總會有單點故障的問題無法解決。一旦Redis服務(wù)進程掛了，或者服務(wù)器1停機了，那么服務(wù)就不可用了。并且如果沒有配置Redis數(shù)據(jù)持久化的話，Redis內(nèi)部已經(jīng)存儲的數(shù)據(jù)也會丟失。

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

為了實現(xiàn)高可用，解決方案1中所述的單點故障問題，我們必須增加一個備份服務(wù)，即在兩臺服務(wù)器上分別各啟動一個Redis Server進程，一般情況下由master提供服務(wù)，slave只負(fù)責(zé)同步和備份。與此同時，在額外啟動一個Sentinel進程，監(jiān)控兩個Redis Server實例的可用性，以便在master掛掉的時候，及時把slave提升到master的角色繼續(xù)提供服務(wù)，這樣就實現(xiàn)了Redis Server的高可用。這基于一個高可用服務(wù)設(shè)計的依據(jù)，即單點故障本身就是個小概率事件，而多個單點同時故障(即master和slave同時掛掉)，可以認(rèn)為是(基本)不可能發(fā)生的事件。

對于Redis服務(wù)的調(diào)用方來說，現(xiàn)在要連接的是Redis Sentinel服務(wù)，而不是Redis Server了。常見的調(diào)用過程是，client先連接Redis Sentinel并詢問目前Redis Server中哪個服務(wù)是master，哪些是slave，然后再去連接相應(yīng)的Redis Server進行操作。當(dāng)然目前的第三方庫一般都已經(jīng)實現(xiàn)了這一調(diào)用過程，不再需要我們手動去實現(xiàn)(例如Nodejs的ioredis，PHP的predis，Golang的go-redis/redis，JAVA的jedis等)。

然而，我們實現(xiàn)了Redis Server服務(wù)的主從切換之后，又引入了一個新的問題，即Redis Sentinel本身也是個單點服務(wù)，一旦Sentinel進程掛了，那么客戶端就沒辦法鏈接Sentinel了。所以說，方案2的配置并無法實現(xiàn)高可用性。

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

為了解決方案2的問題，我們把Redis Sentinel進程也額外啟動一份，兩個Sentinel進程同時為客戶端提供服務(wù)發(fā)現(xiàn)的功能。對于客戶端來說，它可以連接任何一個Redis Sentinel服務(wù)，來獲取當(dāng)前Redis Server實例的基本信息。通常情況下，我們會在Client端配置多個Redis Sentinel的鏈接地址，Client一旦發(fā)現(xiàn)某個地址連接不上，會去試圖連接其他的Sentinel實例，這當(dāng)然也不需要我們手動實現(xiàn)，各個開發(fā)語言中比較熱門的redis連接庫都幫我們實現(xiàn)了這個功能。我們預(yù)期是：即使其中一個Redis Sentinel掛掉了，還有另外一個Sentinel可以提供服務(wù)。

然而，愿景是美好的，現(xiàn)實卻是很殘酷的。如此架構(gòu)下，依然無法實現(xiàn)Redis服務(wù)的高可用。方案3示意圖中，紅線部分是兩臺服務(wù)器之間的通信，而我們所設(shè)想的異常場景(【異常2】)是，某臺服務(wù)器整體down機，不妨假設(shè)服務(wù)器1停機，此時，只剩下服務(wù)器2上面的Redis Sentinel和slave Redis Server進程。這時，Sentinel其實是不會將僅剩的slave切換成master繼續(xù)服務(wù)的，也就導(dǎo)致Redis服務(wù)不可用，因為Redis的設(shè)定是只有當(dāng)超過50%的Sentinel進程可以連通并投票選取新的master時，才會真正發(fā)生主從切換。本例中兩個Sentinel只有一個可以連通，等于50%并不在可以主從切換的場景中。

你可能會問，為什么Redis要有這個50%的設(shè)定?假設(shè)我們允許小于等于50%的Sentinel連通的場景下也可以進行主從切換。試想一下【異常3】，即服務(wù)器1和服務(wù)器2之間的網(wǎng)絡(luò)中斷，但是服務(wù)器本身是可以運行的。如下圖所示：

實際上對于服務(wù)器2來說，服務(wù)器1直接down掉和服務(wù)器1網(wǎng)絡(luò)連不通是一樣的效果，反正都是突然就無法進行任何通信了。假設(shè)網(wǎng)絡(luò)中斷時我們允許服務(wù)器2的Sentinel把slave切換為master，結(jié)果就是你現(xiàn)在擁有了兩個可以對外提供服務(wù)的Redis Server。Client做任何的增刪改操作，有可能落在服務(wù)器1的Redis上，也有可能落在服務(wù)器2的Redis上(取決于Client到底連通的是哪個Sentinel)，造成數(shù)據(jù)混亂。即使后面服務(wù)器1和服務(wù)器2之間的網(wǎng)絡(luò)又恢復(fù)了，那我們也無法把數(shù)據(jù)統(tǒng)一了(兩份不一樣的數(shù)據(jù)，到底該信任誰呢?)，數(shù)據(jù)一致性完全被破壞。

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

鑒于方案3并沒有辦法做到高可用，我們最終的版本就是上圖所示的方案4了。實際上這就是我們最終搭建的架構(gòu)。我們引入了服務(wù)器3，并且在3上面又搭建起一個Redis Sentinel進程，現(xiàn)在由三個Sentinel進程來管理兩個Redis Server實例。這種場景下，不管是單一進程故障、還是單個機器故障、還是某兩個機器網(wǎng)絡(luò)通信故障，都可以繼續(xù)對外提供Redis服務(wù)。

實際上，如果你的機器比較空閑，當(dāng)然也可以把服務(wù)器3上面也開啟一個Redis Server，形成1 master + 2 slave的架構(gòu)，每個數(shù)據(jù)都有兩個備份，可用性會提升一些。當(dāng)然也并不是slave越多越好，畢竟主從同步也是需要時間成本的。

在方案4中，一旦服務(wù)器1和其他服務(wù)器的通信完全中斷，那么服務(wù)器2和3會將slave切換為master。對于客戶端來說，在這么一瞬間會有2個master提供服務(wù)，并且一旦網(wǎng)絡(luò)恢復(fù)了，那么所有在中斷期間落在服務(wù)器1上的新數(shù)據(jù)都會丟失。如果想要部分解決這個問題，可以配置Redis Server進程，讓其在檢測到自己網(wǎng)絡(luò)有問題的時候，立即停止服務(wù)，避免在網(wǎng)絡(luò)故障期間還有新數(shù)據(jù)進來(可以參考Redis的min-slaves-to-write和min-slaves-max-lag這兩個配置項)。

至此，我們就用3臺機器搭建了一個高可用的Redis服務(wù)。其實網(wǎng)上還有更加節(jié)省機器的辦法，就是把一個Sentinel進程放在Client機器上，而不是服務(wù)提供方的機器上。只不過在公司里面，一般服務(wù)的提供方和調(diào)用方并不來自同一個團隊。兩個團隊共同操作同一個機器，很容易因為溝通問題導(dǎo)致一些誤操作，所以出于這種人為因素的考慮，我們還是采用了方案4的架構(gòu)。并且由于服務(wù)器3上面只跑了一個Sentinel進程，對服務(wù)器資源消耗并不多，還可以用服務(wù)器3來跑一些其他的服務(wù)。

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

作為服務(wù)的提供方，我們總是會講到用戶體驗問題。在上述方案當(dāng)中始終有一個讓Client端用的不是那么舒服的地方。對于單機版Redis，Client端直接連接Redis Server，我們只需要給一個ip和port，Client就可以使用我們的服務(wù)了。而改造成Sentinel模式之后，Client不得不采用一些支持Sentinel模式的外部依賴包，并且還要修改自己的Redis連接配置，這對于“矯情”的用戶來講顯然是不能接收的。有沒有辦法還是像在使用單機版的Redis那樣，只給Client一個固定的ip和port就可以提供服務(wù)呢?

答案當(dāng)然是肯定的。這可能就要引入虛擬IP(Virtual IP，VIP)，如上圖所示。我們可以把虛擬IP指向Redis Server master所在的服務(wù)器，在發(fā)生Redis主從切換的時候，會觸發(fā)一個回調(diào)腳本，回調(diào)腳本中將VIP切換至slave所在的服務(wù)器。這樣對于Client端來說，他仿佛在使用的依然是一個單機版的高可用Redis服務(wù)。

結(jié)語

搭建任何一個服務(wù)，做到“能用”其實是非常簡單的，就像我們運行一個單機版的Redis。不過一旦要做到“高可用”，事情就會變得復(fù)雜起來。業(yè)務(wù)中使用了額外的兩臺服務(wù)器，3個Sentinel進程+1個Slave進程，只是為了保證在那小概率的事故中依然做到服務(wù)可用。在實際業(yè)務(wù)中我們還啟用了supervisor做進程監(jiān)控，一旦進程意外退出，會自動嘗試重新啟動。