高可用Redis服務(wù)架構(gòu)分析與搭建

高可用Redis服務(wù)架構(gòu)分析與搭建基于內(nèi)存的Redis應(yīng)該是目前各種web開發(fā)業(yè)務(wù)中最為常用的key-value數(shù)據(jù)庫(kù)了，我們經(jīng)常在業(yè)務(wù)中用其存儲(chǔ)用戶登陸態(tài)（Session存儲(chǔ)），加速一些熱數(shù)據(jù)的查詢（相比較mysql而言，速度有數(shù)量級(jí)的提升），做簡(jiǎn)單的消息隊(duì)列（LPUSH和BRPOP）、訂閱發(fā)布（PUB/SUB）系統(tǒng)等等。規(guī)模比較大的互聯(lián)網(wǎng)公司，一般都會(huì)有專門的團(tuán)隊(duì)，將Redis存儲(chǔ)以基礎(chǔ)服務(wù)的形式提供給各個(gè)業(yè)務(wù)調(diào)用。不過(guò)任何一個(gè)基礎(chǔ)服務(wù)的提供方，都會(huì)被調(diào)用方問(wèn)起的一個(gè)問(wèn)題是：你的服務(wù)是否具有高可用性？最好不要因?yàn)槟愕姆?wù)經(jīng)常出問(wèn)題，導(dǎo)致我這邊的業(yè)務(wù)跟著遭殃。最近我所在的項(xiàng)目中也自己搭了一套小型的“高可用”Redis服務(wù)，在此做一下自己的總結(jié)和思考。首先我們要定義一下對(duì)于Redis服務(wù)來(lái)說(shuō)怎樣才算是高可用，即在各種出現(xiàn)異常的情況下，依然可以正常提供服務(wù)?；蛘邔捤梢恍?，出現(xiàn)異常的情況下，只經(jīng)過(guò)很短暫的時(shí)間即可恢復(fù)正常服務(wù)。所謂異常，應(yīng)該至少包含了以下幾種可能性：【異常1】某個(gè)節(jié)點(diǎn)服務(wù)器的某個(gè)進(jìn)程突然down掉（例如某開發(fā)手殘，把一臺(tái)服務(wù)器的redis-server進(jìn)程kill了）【異常2】某臺(tái)節(jié)點(diǎn)服務(wù)器down掉，相當(dāng)于這個(gè)節(jié)點(diǎn)上所有進(jìn)程都停了（例如某運(yùn)維手殘，把一個(gè)服務(wù)器的電源拔了；例如一些老舊機(jī)器出現(xiàn)硬件故障）【異常3】任意兩個(gè)節(jié)點(diǎn)服務(wù)器之間的通信中斷了（例如某臨時(shí)工手殘，把用于兩個(gè)機(jī)房通信的光纜挖斷了）其實(shí)以上任意一種異常都是小概率事件，而做到高可用性的基本指導(dǎo)思想就是：多個(gè)小概率事件同時(shí)發(fā)生的概率可以忽略不計(jì)。只要我們?cè)O(shè)計(jì)的系統(tǒng)可以容忍短時(shí)間內(nèi)的單點(diǎn)故障，即可實(shí)現(xiàn)高可用性。對(duì)于搭建高可用Redis服務(wù)，網(wǎng)上已有了很多方案，例如Keepalived，Codis，Twemproxy，RedisSentinel。其中Codis和Twemproxy主要是用于大規(guī)模的Redis集群中，也是在Redis官方發(fā)布RedisSentinel之前twitter和豌豆莢提供的開源解決方案。我的業(yè)務(wù)中數(shù)據(jù)量并不大，所以搞集群服務(wù)反而是浪費(fèi)機(jī)器了。最終在Keepalived和RedisSentinel之間做了個(gè)選擇，選擇了官方的解決方案RedisSentinel。RedisSentinel可以理解為一個(gè)監(jiān)控RedisServer服務(wù)是否正常的進(jìn)程，并且一旦檢測(cè)到不正常，可以自動(dòng)地將備份（slave）RedisServer啟用，使得外部用戶對(duì)Redis服務(wù)內(nèi)部出現(xiàn)的異常無(wú)感知。我們按照由簡(jiǎn)至繁的步驟，搭建一個(gè)最小型的高可用的Redis服務(wù)。

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

方案2：主從同步RedisServer，單實(shí)例Sentinel為了實(shí)現(xiàn)高可用，解決方案1中所述的單點(diǎn)故障問(wèn)題，我們必須增加一個(gè)備份服務(wù)，即在兩臺(tái)服務(wù)器上分別各啟動(dòng)一個(gè)RedisServer進(jìn)程，一般情況下由master提供服務(wù)，slave只負(fù)責(zé)同步和備份。與此同時(shí)，在額外啟動(dòng)一個(gè)Sentinel進(jìn)程，監(jiān)控兩個(gè)RedisServer實(shí)例的可用性，以便在master掛掉的時(shí)候，及時(shí)把slave提升到master的角色繼續(xù)提供服務(wù)，這樣就實(shí)現(xiàn)了RedisServer的高可用。這基于一個(gè)高可用服務(wù)設(shè)計(jì)的依據(jù)，即單點(diǎn)故障本身就是個(gè)小概率事件，而多個(gè)單點(diǎn)同時(shí)故障（即master和slave同時(shí)掛掉），可以認(rèn)為是（基本）不可能發(fā)生的事件。對(duì)于Redis服務(wù)的調(diào)用方來(lái)說(shuō)，現(xiàn)在要連接的是RedisSentinel服務(wù)，而不是RedisServer了。常見的調(diào)用過(guò)程是，client先連接RedisSentinel并詢問(wèn)目前RedisServer中哪個(gè)服務(wù)是master，哪些是slave，然后再去連接相應(yīng)的RedisServer進(jìn)行操作。當(dāng)然目前的第三方庫(kù)一般都已經(jīng)實(shí)現(xiàn)了這一調(diào)用過(guò)程，不再需要我們手動(dòng)去實(shí)現(xiàn)（例如Nodejs的ioredis，PHP的predis，Golang的go-redis/redis，JAVA的jedis等）。然而，我們實(shí)現(xiàn)了RedisServer服務(wù)的主從切換之后，又引入了一個(gè)新的問(wèn)題，即RedisSentinel本身也是個(gè)單點(diǎn)服務(wù)，一旦Sentinel進(jìn)程掛了，那么客戶端就沒(méi)辦法鏈接Sentinel了。所以說(shuō)，方案2的配置并無(wú)法實(shí)現(xiàn)高可用性。

方案3：主從同步RedisServer，雙實(shí)例Sentinel為了解決方案2的問(wèn)題，我們把RedisSentinel進(jìn)程也額外啟動(dòng)一份，兩個(gè)Sentinel進(jìn)程同時(shí)為客戶端提供服務(wù)發(fā)現(xiàn)的功能。對(duì)于客戶端來(lái)說(shuō)，它可以連接任何一個(gè)RedisSentinel服務(wù)，來(lái)獲取當(dāng)前RedisServer實(shí)例的基本信息。通常情況下，我們會(huì)在Client端配置多個(gè)RedisSentinel的鏈接地址，Client一旦發(fā)現(xiàn)某個(gè)地址連接不上，會(huì)去試圖連接其他的Sentinel實(shí)例，這當(dāng)然也不需要我們手動(dòng)實(shí)現(xiàn)，各個(gè)開發(fā)語(yǔ)言中比較熱門的redis連接庫(kù)都幫我們實(shí)現(xiàn)了這個(gè)功能。我們預(yù)期是：即使其中一個(gè)RedisSentinel掛掉了，還有另外一個(gè)Sentinel可以提供服務(wù)。然而，愿景是美好的，現(xiàn)實(shí)卻是很殘酷的。如此架構(gòu)下，依然無(wú)法實(shí)現(xiàn)Redis服務(wù)的高可用。方案3示意圖中，紅線部分是兩臺(tái)服務(wù)器之間的通信，而我們所設(shè)想的異常場(chǎng)景（【異常2】）是，某臺(tái)服務(wù)器整體down機(jī)，不妨假設(shè)服務(wù)器1停機(jī)，此時(shí)，只剩下服務(wù)器2上面的RedisSentinel和slaveRedisServer進(jìn)程。這時(shí)，Sentinel其實(shí)是不會(huì)將僅剩的slave切換成master繼續(xù)服務(wù)的，也就導(dǎo)致Redis服務(wù)不可用，因?yàn)镽edis的設(shè)定是只有當(dāng)超過(guò)50%的Sentinel進(jìn)程可以連通并投票選取新的master時(shí)，才會(huì)真正發(fā)生主從切換。本例中兩個(gè)Sentinel只有一個(gè)可以連通，等于50%并不在可以主從切換的場(chǎng)景中。你可能會(huì)問(wèn)，為什么Redis要有這個(gè)50%的設(shè)定？假設(shè)我們?cè)试S小于等于50%的Sentinel連通的場(chǎng)景下也可以進(jìn)行主從切換。試想一下【異常3】，即服務(wù)器1和服務(wù)器2之間的網(wǎng)絡(luò)中斷，但是服務(wù)器本身是可以運(yùn)行的。如下圖所示：實(shí)際上對(duì)于服務(wù)器2來(lái)說(shuō)，服務(wù)器1直接down掉和服務(wù)器1網(wǎng)絡(luò)連不通是一樣的效果，反正都是突然就無(wú)法進(jìn)行任何通信了。假設(shè)網(wǎng)絡(luò)中斷時(shí)我們?cè)试S服務(wù)器2的Sentinel把slave切換為master，結(jié)果就是你現(xiàn)在擁有了兩個(gè)可以對(duì)外提供服務(wù)的RedisServer。Client做任何的增刪改操作，有可能落在服務(wù)器1的Redis上，也有可能落在服務(wù)器2的Redis上（取決于Client到底連通的是哪個(gè)Sentinel），造成數(shù)據(jù)混亂。即使后面服務(wù)器1和服務(wù)器2之間的網(wǎng)絡(luò)又恢復(fù)了，那我們也無(wú)法把數(shù)據(jù)統(tǒng)一了（兩份不一樣的數(shù)據(jù)，到底該信任誰(shuí)呢？），數(shù)據(jù)一致性完全被破壞。搜索公眾號(hào)后端架構(gòu)師后臺(tái)回復(fù)“架構(gòu)整潔”，獲取一份驚喜禮包。

方案4：主從同步RedisServer，三實(shí)例Sentinel鑒于方案3并沒(méi)有辦法做到高可用，我們最終的版本就是上圖所示的方案4了。實(shí)際上這就是我們最終搭建的架構(gòu)。我們引入了服務(wù)器3，并且在3上面又搭建起一個(gè)RedisSentinel進(jìn)程，現(xiàn)在由三個(gè)Sentinel進(jìn)程來(lái)管理兩個(gè)RedisServer實(shí)例。這種場(chǎng)景下，不管是單一進(jìn)程故障、還是單個(gè)機(jī)器故障、還是某兩個(gè)機(jī)器網(wǎng)絡(luò)通信故障，都可以繼續(xù)對(duì)外提供Redis服務(wù)。實(shí)際上，如果你的機(jī)器比較空閑，當(dāng)然也可以把服務(wù)器3上面也開啟一個(gè)RedisServer，形成1master+2slave的架構(gòu)，每個(gè)數(shù)據(jù)都有兩個(gè)備份，可用性會(huì)提升一些。當(dāng)然也并不是slave越多越好，畢竟主從同步也是需要時(shí)間成本的。在方案4中，一旦服務(wù)器1和其他服務(wù)器的通信完全中斷，那么服務(wù)器2和3會(huì)將slave切換為master。對(duì)于客戶端來(lái)說(shuō)，在這么一瞬間會(huì)有2個(gè)master提供服務(wù)，并且一旦網(wǎng)絡(luò)恢復(fù)了，那么所有在中斷期間落在服務(wù)器1上的新數(shù)據(jù)都會(huì)丟失。如果想要部分解決這個(gè)問(wèn)題，可以配置RedisServer進(jìn)程，讓其在檢測(cè)到自己網(wǎng)絡(luò)有問(wèn)題的時(shí)候，立即停止服務(wù)，避免在網(wǎng)絡(luò)故障期間還有新數(shù)據(jù)進(jìn)來(lái)（可以參考Redis的min-slaves-to-write和min-slaves-max-lag這兩個(gè)配置項(xiàng)）。至此，我們就用3臺(tái)機(jī)器搭建了一個(gè)高可用的Redis服務(wù)。其實(shí)網(wǎng)上還有更加節(jié)省機(jī)器的辦法，就是把一個(gè)Sentinel進(jìn)程放在Client機(jī)器上，而不是服務(wù)提供方的機(jī)器上。只不過(guò)在公司里面，一般服務(wù)的提供方和調(diào)用方并不來(lái)自同一個(gè)團(tuán)隊(duì)。兩個(gè)團(tuán)隊(duì)共同操作同一個(gè)機(jī)器，很容易因?yàn)闇贤▎?wèn)題導(dǎo)致一些誤操作，所以出于這種人為因素的考慮，我們還是采用了方案4的架構(gòu)。并且由于服務(wù)器3上面只跑了一個(gè)Sentinel進(jìn)程，對(duì)服務(wù)器資源消耗并不多，還可以用服務(wù)器3來(lái)跑一些其他的服務(wù)。

易用性：像使用單機(jī)版Redis一樣使用RedisSentinel作為服務(wù)的提供方，我們總是會(huì)講到用戶體驗(yàn)問(wèn)題。在上述方案當(dāng)中始終有一個(gè)讓Client端用的不是那么舒服的地方。對(duì)于單機(jī)版Redis，Client端直接連接RedisServer，我們只需要給一個(gè)ip和port，Client就可以使用我們的服務(wù)了。而改造成Sentinel模式之后，Client不得不采用一些支持Sentinel模式的外部依賴包，并且還要修改自己的Redis連接配置，這對(duì)于“矯情”的用戶來(lái)講顯然是不能接收的。有沒(méi)有辦法還是像在使用單機(jī)版的Redis那樣，只給Client一個(gè)固定的ip和port就可以提供服務(wù)呢？答案當(dāng)然是肯定的。這可能就要引入虛擬IP（VirtualIP，VIP），如上圖所示。我們可以把虛擬IP指向RedisServermaster所在的服務(wù)器，在發(fā)生Redis主從切換的時(shí)候，會(huì)觸發(fā)一個(gè)回調(diào)腳本，回調(diào)腳本中將VIP切換至slav