Linux下搭建高可用Redis緩存

Redis是一個高性能的key-value資料庫，現時越來越多企業與應用使用Redis作為緩存伺服器。樓主是一枚JAVA後端程序員，也算是半個運維工程師了。在Linux伺服器上搭建Redis，怎麼可以不會呢？下面樓主就帶著大家從0開始，依次搭建：Redis單機伺服器 -> Redis主從複製 -> Redis-Sentinel高可用。逐步搭建出高可用的Redis緩存伺服器。

搭建Redis

1. 下載並解壓

首先從Redis官網下載Redis並解壓，樓主使用的版本是4.0.2。依次執行如下命令：

如果沒有安裝gcc依賴包，則安裝對應依賴包

2. 編譯並安裝

下載並解壓完畢後，則對源碼包進行編譯安裝，樓主的Redis安裝路徑為/usr/local/redis，同學們可以自行修改語句：make install PREFIX=你想要安裝的路徑

複製Redis相關命令到/usr/sbin目錄下，這樣就可以直接執行這些命令，不用寫全路徑

3. 建立Redis配置文件

安裝完成之後將 Redis 配置文件拷貝到系統配置目錄/etc/下，redis.conf 是 Redis 的配置文件，redis.conf 在 Redis 源碼目錄，port默認 6379。

Redis配置文件主要參數解析參考

3.1 設置後端啟動：

由於Redis默認是前端啟動，必須保持在當前的窗口中，如果使用ctrl + c退出，那麼Redis也就退出，不建議使用。

修改Redis配置文件把舊值daemonize no 改為 新值daemonize yes

3.2 設置訪問：

Redis默認只允許本機訪問，可是有時候我們也需要 Redis 被遠程訪問。

找到 bind 那行配置，默認是： # bind 127.0.0.1

去掉#注釋並改為： bind 0.0.0.0 此設置會變成允許所有遠程訪問。如果想指定限制訪問，可設置對應的IP。

3.3 配置Redis日誌記錄：

找到logfile那行配置，默認是：logfile ""，改為logfile /var/log/redis_6379.log

3.4 設置 Redis 請求密碼：

找到默認是被注釋的這一行：# requirepass foobared

去掉注釋，把 foobared 改為你想要設置的密碼，比如我打算設置為：123456，所以我改為：requirepass "123456"

修改之後重啟下服務

有了密碼之後，進入客戶端，就得這樣訪問：redis-cli -h 127.0.0.1 -p 6379 -a 123456

4. Redis常用操作4.1 啟動

4.2 關閉

4.3 查看是否啟動

4.4 進入客戶端

4.5 關閉客戶端

4.6 設置開機自動啟動配置

4.7 開放防火牆埠

5. 將Redis註冊為系統服務

在/etc/init.d目錄下添加Redis服務的啟動，暫停和重啟腳本：

腳本內容如下：

賦予腳本許可權

啟動、停止和重啟：

至此，Redis單機伺服器已搭建完畢，下面我們看看主從架構如何搭建。

搭建Redis主從架構

1. redis-server說明

2. Redis主從架構配置

編輯從機的 Redis 配置文件，找到 210 行（大概），默認這一行應該是注釋的： # slaveof

我們需要去掉該注釋，並且填寫我們自己的主機的 IP 和 埠，比如：slaveof 172.16.2.185 6379，如果主機設置了密碼，還需要找到masterauth這一行，去掉注釋，改為masterauth主機密碼。

配置完成後重啟從機Redis服務

重啟完之後，進入主機的 redis-cli 狀態下redis-cli -h 127.0.0.1 -p 6379 -a 123456，輸入：INFO replication

可以查詢到當前主機的 Redis處於什麼角色，有哪些從機已經連上主機。

主機信息172.16.2.185

從機信息172.16.2.181

此時已經完成了主從配置，我們可以測試下：

我們進入主機的 redis-cli 狀態，然後 set 某個值，比如：set myblog YouMeek.com

我們切換進入從機的 redis-cli 的狀態下，獲取剛剛設置的值看是否存在：get myblog，此時，我們可以發現是可以獲取到值的。

3. Redis主從架構總結

需要注意的是：從庫不具備寫入數據能力，不然會報錯。 從庫只有隻讀能力。

主從架構的優點：除了減少主庫連接的壓力，還有可以關掉主庫的持久化功能，把持久化的功能交給從庫進行處理。

第一個從庫配置的信息是連上主庫，後面的第二個從庫配置的連接信息是連上第一個從庫， 假如還有第三個從庫的話，我們可以把第三個從庫的配置信息連上第二個從庫上，以此類推。

Redis Sentinel高可用架構搭建

1. 自動故障轉移

雖然使用主從架構配置Redis做了備份，看上去很完美。但由於Redis目前只支持主從複製備份（不支持主主複製），當主Redis掛了，從Redis只能提供讀服務，無法提供寫服務。所以，還得想辦法，當主Redis掛了，讓從Redis升級成為主Redis。

這就需要自動故障轉移，Redis Sentinel帶有這個功能，當一個主Redis不能提供服務時，Redis Sentinel可以將一個從Redis升級為主Redis，並對其他從Redis進行配置，讓它們使用新的主Redis進行複製備份。

注意：搭建Redis Sentinel推薦至少3台伺服器，但由於樓主偷懶，下面用例只用了2台伺服器。

Redis Sentinel的主要功能如下：

監控：哨兵不斷的檢查master和slave是否正常的運行。

通知：當監控的某台Redis實例發生問題時，可以通過API通知系統管理員和其他的應用程序。

自動故障轉移：如果一個master不正常運行了，哨兵可以啟動一個故障轉移進程，將一個slave升級成為master，其他的slave被重新配置使用新的master，並且應用程序使用Redis服務端通知的新地址。

配置提供者：哨兵作為Redis客戶端發現的權威來源：客戶端連接到哨兵請求當前可靠的master的地址。如果發生故障，哨兵將報告新地址。

默認情況下，每個Sentinel節點會以每秒一次的頻率對Redis節點和其它的Sentinel節點發送PING命令，並通過節點的回復來判斷節點是否在線。

如果在down-after-millisecondes毫秒內，沒有收到有效的回復，則會判定該節點為主觀下線。

如果該節點為master，則該Sentinel節點會通過sentinel is-master-down-by-addr命令向其它sentinel節點詢問對該節點的判斷，如果超過個數的節點判定master不可達，則該sentinel節點會將master判斷為客觀下線。

這個時候，各個Sentinel會進行協商，選舉出一個領頭Sentinel，由該領頭Sentinel對master節點進行故障轉移操作。

故障轉移包含如下三個操作：

在所有的slave伺服器中，挑選出一個slave，並將其轉換為master。

讓其它slave伺服器，改為複製新的master。

將舊master設置為新master的slave，這樣，當舊的master重新上線時，它會成為新master的slave。

2. 搭建Redis Sentinel高可用架構

這裡使用兩台伺服器，每台伺服器上開啟一個redis-server和redis-sentinel服務。

redis-server說明

redis-sentinel說明

2.1 建立Redis配置文件

如果要做自動故障轉移，則建議所有的redis.conf都設置masterauth，因為自動故障只會重寫主從關係，即slaveof，不會自動寫入masterauth。如果Redis原本沒有設置密碼，則可以忽略。

Redis程序上面已經安裝過了，我們只需增加redis-sentinel的相關配置即可，將 redis-sentinel的配置文件拷貝到系統配置目錄/etc/下，sentinel.conf 是 redis-sentinel的配置文件，sentinel.conf 在 Redis 源碼目錄。

修改sentinel.conf配置文件內容如下：

在配置最後加上

配置文件說明：

1.port :當前Sentinel服務運行的埠

2.dir : Sentinel服務運行時使用的臨時文件夾

3.sentinel monitor master001 192.168.110.10163792:Sentinel去監視一個名為master001的主redis實例，這個主實例的IP地址為本機地址192.168.110.101，埠號為6379，而將這個主實例判斷為失效至少需要2個 Sentinel進程的同意，只要同意Sentinel的數量不達標，自動failover就不會執行

4.sentinel down-after-milliseconds master001 30000:指定了Sentinel認為Redis實例已經失效所需的毫秒數。當實例超過該時間沒有返回PING，或者直接返回錯誤，那麼Sentinel將這個實例標記為主觀下線。只有一個 Sentinel進程將實例標記為主觀下線並不一定會引起實例的自動故障遷移：只有在足夠數量的Sentinel都將一個實例標記為主觀下線之後，實例才會被標記為客觀下線，這時自動故障遷移才會執行

5.sentinel parallel-syncs master001 1：指定了在執行故障轉移時，最多可以有多少個從Redis實例在同步新的主實例，在從Redis實例較多的情況下這個數字越小，同步的時間越長，完成故障轉移所需的時間就越長

6.sentinel failover-timeout master001 180000：如果在該時間（ms）內未能完成failover操作，則認為該failover失敗

7.sentinel notification-script ：指定sentinel檢測到該監控的redis實例指向的實例異常時，調用的報警腳本。該配置項可選，但是很常用

2.2 開放防火牆埠

2.3 啟動redis-sentinel

在任意一台機子均可查看到相關服務信息

3. 自動故障轉移測試3.1 停止主Redis

3.2 查看redis-sentinel的監控狀態

發現從庫提升為主庫。

3.3 注意事項

如果停掉master後，Sentinel顯示足夠數量的sdown後，沒有出現odown或try-failover，則檢查密碼等配置是否正確

如果停掉master後，試圖切換的時候，發現日誌出現 failover-abort-not-elected，則分2種情況分別解決：

1. 如果Redis實例沒有配置

則在Sentinel 配置文件加上protected-mode no即可

2. 如果Redis實例有配置

則在Sentinel配置文件加上

至此，redis的高可用方案已經搭建完成。

VIP對外提供虛擬IP實現高可用

1. 現有情況概述

客戶端程序（如JAVA程序）連接Redis時需要ip和port，但redis-server進行故障轉移時，主Redis是變化的，所以ip地址也是變化的。客戶端程序如何感知當前主Redis的ip地址和埠呢？redis-sentinel提供了介面，請求任何一個Sentinel，發送SENTINEL get-master-addr-by-name就能得到當前主Redis的ip和port。

客戶端每次連接Redis前，先向sentinel發送請求，獲得主Redis的ip和port，然後用返回的ip和port連接Redis。

這種方法的缺點是顯而易見的，每次操作Redis至少需要發送兩次連接請求，第一次請求Sentinel，第二次請求Redis。

更好的辦法是使用VIP，當然這對配置的環境有一定的要求，比如Redis搭建在阿里雲伺服器上，可能不支持VIP。

VIP方案是，Redis系統對外始終是同一ip地址，當Redis進行故障轉移時，需要做的是將VIP從之前的Redis伺服器漂移到現在新的主Redis伺服器上。

比如：當前Redis系統中主Redis的ip地址是172.16.2.185，那麼VIP(172.16.2.250)指向172.16.2.185，客戶端程序用VIP(172.16.2.250)地址連接Redis，實際上連接的就是當前主Redis，這樣就避免了向Sentinel發送請求。

當主Redis宕機，進行故障轉移時，172.16.2.181這台伺服器上的Redis提升為主，這時VIP（172.16.2.250）指向172.16.2.181，這樣客戶端程序不需要修改任何代碼，連接的是172.16.2.181這台主Redis。

2.漂移VIP實現Redis故障轉移

那麼現在的問題是，如何在進行Redis故障轉移時，將VIP漂移到新的主Redis伺服器上。

這裡可以使用Redis Sentinel的一個參數client-reconfig-script，這個參數配置執行腳本，Sentinel在做failover的時候會執行這個腳本，並且傳遞6個參數，其中是新主Redis的IP地址，可以在這個腳本里做VIP漂移操作。

修改兩個伺服器的redis-sentinel配置文件/etc/sentinel.conf，增加上面一行。然後在/opt/目錄下創建notify_mymaster.sh腳本文件，這個腳本做VIP漂移操作，內容如下:

賦予腳本許可權

現在當前主Redis是172.16.2.185，需要手動綁定VIP到該伺服器上。

由於VIP只能綁定只有一台機子，所以建議將改為bind 0.0.0.0添加至redis.conf 中

設置bind 0.0.0.0

由於VIP只能綁定只有一台機子，所以建議將改為bind 0.0.0.0添加至sentinel.conf中

設置bind 0.0.0.0

重啟Redis

重啟Sentinel

隨後我們在另一台機器172.16.2.181上，通過VIP訪問主機

可正常通訊，信息如下：

訪問主機的Sentinel

可正常通訊，信息如下：

下面關閉主機的Redis服務，看看VIP是否漂移到另一台伺服器上。

查看是否已進行切換

通過查詢Sentinel發現從機172.16.2.181提升為主。

通過訪問VIP的方式連接Redis

從上面信息可知，VIP已經飄移成功。可喜可賀，大吉大利，晚上吃雞。

總結

至此，高可用Redis緩存服務已搭建完畢，遲點會再出一篇文章教大家如何通過JAVA連接Redis進行相關操作。至於Redis Cluster集群方案，等有空再搭建然後再和大家一同分享。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！