<dd id="yzu3f"><tr id="yzu3f"><kbd id="yzu3f"></kbd></tr></dd>

              黑基Web安全攻防班
              安基網 首頁 IT技術 網絡管理 查看內容

              教你用 3 臺機器搞定一個 Redis 高可用架構

              2018-9-23 09:13| 投稿: xiaotiger |來自: 互聯網

              摘要: 基于內存的 Redis 應該是目前各種 Web 開發業務中最為常用的 key-value 數據庫了。我們經常在業務中用其存儲用戶登陸態(Session 存儲),加速一些熱數據的查詢(相比較 MySQL 而言,速度有數量級的提升),做簡單的 ...

              基于內存的 Redis 應該是目前各種 Web 開發業務中最為常用的 key-value 數據庫了。

              我們經常在業務中用其存儲用戶登陸態(Session 存儲),加速一些熱數據的查詢(相比較 MySQL 而言,速度有數量級的提升),做簡單的消息隊列(LPUSH 和 BRPOP)、訂閱發布(PUB/SUB)系統等等。

              規模比較大的互聯網公司,一般都會有專門的團隊,將 Redis 存儲以基礎服務的形式提供給各個業務調用。

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

              最近在我的項目中自己搭了一套小型的“高可用”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 面試題及答案。

              下面我們按照由簡至繁的步驟,搭建一個最小型的高可用的 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 面試題及答案。

              我們預期是:即使其中一個 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),造成數據混亂。點擊這里獲取全套 redis 面試題及答案。

              即使后面服務器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 面試題及答案。

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



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

              我們可以把虛擬 IP 指向 Redis Server master 所在的服務器,在發生 Redis 主從切換的時候,會觸發一個回調腳本,回調腳本中將 VIP 切換至 slave 所在的服務器。

              這樣對于 Client 端來說,他仿佛在使用的依然是一個單機版的高可用 Redis 服務。

              結語


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

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

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


              小編推薦:欲學習電腦技術、系統維護、網絡管理、編程開發和安全攻防等高端IT技術,請 點擊這里 注冊賬號,公開課頻道價值萬元IT培訓教程免費學,讓您少走彎路、事半功倍,好工作升職加薪!

              本文出自:https://www.toutiao.com/a6603115795910230532/

              免責聲明:本文由投稿者轉載自互聯網,版權歸原作者所有,文中所述不代表本站觀點,若有侵權或轉載等不當之處請聯系我們處理,讓我們一起為維護良好的互聯網秩序而努力!聯系方式見網站首頁右下角。


              鮮花

              握手

              雷人

              路過

              雞蛋

              相關閱讀

              最新評論

              最新

              返回頂部
              十一选五奖金对照表