<ins id="jxy61"><option id="jxy61"><menu id="jxy61"></menu></option></ins>
          1. 煉數成金 門戶 大數據 Nosql 查看內容

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

            2020-7-24 09:51| 發布者: 煉數成金_小數| 查看: 59489| 評論: 0|來自: 架構之美

            摘要: 基于內存的Redis應該是目前各種web開發業務中最為常用的key-value數據庫了,我們經常在業務中用其存儲用戶登陸態(Session存儲),加速一些熱數據的查詢(相比較mysql而言,速度有數量級的提升),做簡單的消息隊列 ...
            基于內存的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做進程監控,一旦進程意外退出,會自動嘗試重新啟動。

            聲明:文章收集于網絡,版權歸原作者所有,為傳播信息而發,如有侵權,請聯系小編刪除,謝謝!

            歡迎加入本站公開興趣群
            軟件開發技術群
            興趣范圍包括:Java,C/C++,Python,PHP,Ruby,shell等各種語言開發經驗交流,各種框架使用,外包項目機會,學習、培訓、跳槽等交流
            QQ群:26931708

            Hadoop源代碼研究群
            興趣范圍包括:Hadoop源代碼解讀,改進,優化,分布式系統場景定制,與Hadoop有關的各種開源項目,總之就是玩轉Hadoop
            QQ群:288410967 

            鮮花

            握手

            雷人

            路過

            雞蛋

            最新評論

            熱門頻道

            • 大數據

            即將開課

            熱門文章

               

              GMT+8, 2021-5-1 19:08 , Processed in 0.100622 second(s), 23 queries .

              年轻人手机在线观看