Redis 實戰搭建高可用架構

前言：最近在看關於redis緩存方面的知識，今天就來個 Redis sentinel 高可用架構，實戰開始以前，先看看sentinel的概念

 

什麼是redis-sentinel

　　Redis-Sentinel是Redis官方推薦的高可用性(HA)解決方案，當用Redis作Master-slave的高可用方案時，假如master宕機了，
Redis自己(包括它的不少客戶端)都沒有實現自動進行主備切換，而Redis-sentinel自己也是一個獨立運行的進程，它能監控多個master-slave集羣，發現master宕機後能進行自動切換。

 

爲何使用sentinel服務

　　redis的普通主從模式中，當主數據庫遇到異常中斷服務後，開發者能夠經過手動的方式選擇一個從數據庫來升格爲主數據庫，以使得系統可以繼續提供服務。然而整個過程相對麻煩且須要人工介入，難以實現自動化。 
爲此，Redis 2.8開始提供了哨兵工具來實現自動化的系統監控和故障恢復功能。 哨兵的做用就是監控redis主、從數據庫是否正常運行，主出現故障自動將從數據庫轉換爲主數據庫。

 

1、首先實現主從複製（一主多從）

說明：若是這臺服務器出現硬盤故障等問題，也會致使數據丟失。爲了不單點故障，一般的作法是將數據庫複製多個副本以部署在不一樣的服務器上，這樣即便有一臺服務器出現故障，其餘服務器依然能夠繼續提供服務。
　　  爲此， Redis 提供了複製（replication）功能，能夠實現當一臺數據庫中的數據更新後，自動將更新的數據同步到其餘數據庫上。

這裏，咱們把redis.conf做爲master，slave_1.conf和slave_2.conf爲從

　　一、找到redis.conf，複製出2份（我只有一個服務器，因此經過改變端口來實現）

　　

　　二、修改如下幾項配置

一、端口號： slave_1.conf：6380 slave_2.conf：6381 二、綁定 slave_1.conf：slaveof 127.0.0.1 6379 slave_2.conf：slaveof 127.0.0.1 6379 三、密碼（最好跟master一致） slave_1.conf：requirepass 123456
 　　　　slave_2.conf：requirepass 123456

四、驗證密碼（從機對主機驗證時，所需的密碼）
　　　　　slave_1.conf：masterauth 123456
　　　　　　slave_2.conf：masterauth 123456

 　　

　　

　　

　　

　　三、啓動主機和從機

 　　

　　

　　四、驗證結果

　　master：

　　

　　slave_1：

　　

　　slave_2：

　　　

　　五、流程圖

 

能夠看到主機執行寫命令，從機能同步主機的值，主從複製就實現了。

注意：默認狀況下從庫是隻讀的，不能進行修改，須要修改須要設置配置文件中的slave-read-only爲no。在命令行裏執行slaveof no one可讓一個從庫變成主庫。

問題：當主服務器掛了怎麼辦

 

2、引入sentinel（哨兵）模式

特色：
    一、不時地監控redis是否按照預期良好地運行;
    二、若是發現某個redis節點運行出現情況，可以通知另一個進程(例如它的客戶端);
    三、可以進行自動切換。當一個master節點不可用時，可以選舉出master的多個slave(若是有超過一個slave的話)中的一個來做爲新的master,
　　　　其它的slave節點會將它所追隨的master的地址改成被提高爲master的slave的新地址。

　　單點sentinel示意圖

　　集羣sentinel示意圖（防止單點故障）

　　

 　　一、找到sentinel.conf文件

一、找到sentinel.conf文件，默認在redis源碼包裏
二、複製sentinel.conf文件到redis.conf同級目錄

　　二、配置sentinel.conf

說明：我這裏是單個sentinel，集羣sentinel下面方法也通用

一、port : 當前Sentinel服務運行的端口（注意：多個sentinel，記得修改端口號） 二、dir : Sentinel服務運行時使用的臨時文件夾 三、sentinel monitor master001 192.168.110.101 6379 2：Sentinel去監視一個名爲master001的主redis實例，這個主實例的IP地址爲本機地址192.168.110.101，端口號爲6379，
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　而將這個主實例判斷爲失效至少須要2個 Sentinel進程的贊成(注意：若是是單個sentinel，這裏就是1)，只要贊成Sentinel的數量不達標，
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　自動failover就不會執行
 四、sentinel auth-pass mymaster 123456：設置鏈接master和slave時的密碼，注意的是sentinel不能分別爲master和slave設置不一樣的密碼，所以master和slave的密碼應該設置相同。
 四、sentinel down-after-milliseconds master001 30000：指定了Sentinel認爲Redis實例已經失效所需的毫秒數。當實例超過該時間沒有返回PING，或者直接返回錯誤，那麼Sentinel將這個實例標記爲主觀下線。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　只有一個 Sentinel進程將實例標記爲主觀下線並不必定會引發實例的自動故障遷移：只有在足夠數量的Sentinel都將一個實例標記爲主觀下線以後，
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　實例纔會被標記爲客觀下線，這時自動故障遷移纔會執行 五、sentinel parallel-syncs master001 1：指定了在執行故障轉移時，最多能夠有多少個從Redis實例在同步新的主實例，在從Redis實例較多的狀況下這個數字越小，同步的時間越長，完成故障轉移所需的時間就越長 六、sentinel failover-timeout master001 180000：若是在該時間（ms）內未能完成failover操做，則認爲該failover失敗 七、sentinel notification-script <master-name> <script-path>：指定sentinel檢測到該監控的redis實例指向的實例異常時，調用的報警腳本。該配置項可選，可是很經常使用

　　三、啓動sentinel

命令：redis-sentinel  sentinel.conf

說明：redis-sentinel  path (sentinel的配置文件路徑) + filename (文件名)

多個sentinel也同樣，只需修改filename就行

　　

　　啓動後會在控制檯看到以下信息

　　

　　四、測試sentinel自動切換功能

　　　　一、中止主節點（端口爲6379）

　　　　　

　　　　 二、查看slave節點（端口爲6380,6381）

　　　　

　　　　

　　　　能夠看到，已經成功切換了

　　　　三、恢復主節點（master）

　　　　

　　　　以前的主節點變成了slave

　　　五、啓動中碰到的問題

一、redis啓動警告問題：WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
　　緣由：對一個高負載的環境來講tcp設置128這個值，過小了。 
　　解決：
    　　一、臨時：執行  echo 511 > /proc/sys/net/core/somaxconn
    　　二、永久：打開ietc/sysctl.conf，在這裏面添net.core.somaxconn= 1024 而後執行sysctl -p 就能夠永久消除這個warning

二、在控制檯info中沒看到* +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379這類的信息，
　　而是這個sdown master mymaster 127.0.0.1 6379，Next failover delay: I will not start a failover之類的
　　緣由：沒有設置master鏈接密碼
　　解決：在sentinel.conf上設置  sentinel auth-pass mymaster password(master密碼)

三、啓動sentinel出現：*** FATAL CONFIG FILE ERROR ***   Reading the configuration file, at line 104 'sentinel auth-pass mymaster redis'  No such master with specified name.
　　緣由：這是由於設置sentinel auth-pass的時候沒有在sentinel monitor mymaster ...  的下面
　　解決：設置在sentinel monitor mymaster ...  的下面就好了

 　　說明：我上面的例子中，只用了單個sentinel，這會存在單點故障問題。這點須要注意

 

3、官方提供的集羣高可用架構（redis-cluster）

前言：關於redis-cluster，這裏就不實際操做了，有興趣的小夥伴能夠本身去試試。

　　一、這裏簡單說說redis-cluster的做用　　　

　　即便使用哨兵，redis每一個實例也是全量存儲，每一個redis存儲的內容都是完整的數據，浪費內存且有木桶效應。
爲了最大化利用內存，能夠採用cluster羣集，就是分佈式存儲。即每臺redis存儲不一樣的內容。
採用redis-cluster架構正是知足這種分佈式存儲要求的集羣的一種體現。redis-cluster架構中，被設計成共有16384個hash slot。
每一個master分得一部分slot，其算法爲：hash_slot = crc16(key) mod 16384 ，這就找到對應slot。採用hash slot的算法，
其實是解決了redis-cluster架構下，有多個master節點的時候，數據如何分佈到這些節點上去。
key是可用key，若是有{}則取{}內的做爲可用key，不然整個能夠是可用key。羣集至少須要3主3從，且每一個實例使用不一樣的配置文件。

　　示意圖

　　

　　二、redis-cluster架構說明

　　在cluster架構下，默認的，通常redis-master用於接收讀寫，而redis-slave則用於備份，當有請求是在向slave發起時，會直接重定向到對應key所在的master來處理。
但若是不介意讀取的是redis-cluster中有可能過時的數據而且對寫請求不感興趣時，則亦可經過readonly命令，將slave設置成可讀，而後經過slave獲取相關的key，達到讀寫分離。

　　三、注意事項

（1）redis-cluster最小配置爲三主三從，當1個主故障，你們會給對應的從投票，把從立爲主，若沒有從數據庫能夠恢復則redis羣集就down了。

（2）在這個redis cluster中，若是你要在slave讀取數據，那麼須要帶上readonly指令。redis cluster的核心的理念，主要是用slave作高可用的，
　　 每一個master掛一兩個slave，主要是作數據的熱備，當master故障時的做爲主備切換，實現高可用的。redis cluster默認是不支持slave節點讀或者寫的，
　　 跟咱們手動基於replication搭建的主從架構不同的。slave node要設置readonly，而後再get，這個時候才能在slave node進行讀取。對於redis -cluster主從架構，
　　 若要進行讀寫分離，官方實際上是不建議的，但也能作，只是會複雜一些。

（3）redis-cluster的架構下，實際上自己master就是能夠任意擴展的，你若是要支撐更大的讀吞吐量，或者寫吞吐量，或者數據量，均可以直接對master進行橫向擴展就能夠了。
　　 也擴容master，跟以前擴容slave進行讀寫分離，效果是同樣的或者說更好。

（4）可使用自帶客戶端鏈接：使用redis-cli -c -p cluster中任意一個端口，進行數據獲取測試。

 

以上就是所有內容了，sentinel模式爲本人實測