【Redis哨兵集羣】

@

目錄

• 開始配置主從複製
• 開始配置Redis Sentinel

---

在開始以前，咱們先來看看Redis的主從複製

主從複製原理：

1. 從服務器向主服務器發送SYNC命令。
2. 主服務器接到SYNC命令後，會調用BGSAVE命令，建立一個RDB文件，並使用緩衝區記錄接下來執行的全部寫命令。
3. 當主服務器執行完BGSAVE命令後，會向從服務器發送RDB文件，而從服務器則會接收並執行這個文件。
4. 主服務器將緩衝區存儲的全部寫命令發送給從服務器執行。

---------

Redis主從複製使用的是RDB備份方式來同步主從服務器的數據的。
同步開始以後，經過主庫命令傳播的方式，主動複製方式實現。
2.8之後實現PSYNC餓機制，實現斷線重連。

Redis主從複製的背景問題

Reids主從複製可將主節點數據同步給從節點，從節點此時有兩個做用：

1. 一旦主節點宕機，從節點做爲主節點的備份能夠隨時頂上來.
2. 擴展主節點的讀能力，分擔主節點的讀壓力.

.
一旦主節點宕機，從節點上位，那麼就須要人爲修改全部應用方的主節點地址（指定新的master地址），還須要命令全部從節點複製新的主節點.
這個問題很麻煩，而redis-sentinel就能夠很好的解決這個問題.

---

Redis-Sentinel

    Redis-Sentinel是redis官方推薦的高可用性能解決方案，當用redis作master-slave的高可用時，若是master本機宕機，redis自己或者客戶端都沒有實現主從切換的功能，而redis-sentinel是一個獨立運行的進程，用於監控多個maser-slave集羣，其自動發現master宕機，進行自動切換：slave > master

---

Sentinel主要功能

• 不時的監控redis是否良好運行，若是節點不可達就會對節點作下線標示.
• 若是被標示的是主節點，則sentinel就會和其它的sentinel節點「協商」，若是其它節點也認爲主節點不可達，就會選舉一個sentinel節點來完成自動故障轉移.
• 在master-slave進行切換後，master_redis.conf、slave_redis.conf和sentinel.conf的內容都會發生改變，即master_redis.conf中會多一行slaveof的配置，sentinel.conf的監控目標會隨之調換.

---

Sentinel工做原理

每個Sentinel以每秒鐘一次的頻率向它所知的全部Master、Slave以及其它Sentinel實例發送一個PING命令.

若是一個實例(Instance)距離最後一次有效回覆PING命令的時間超過down-after-milliseconds選項所指定的值，則這個實例會被Sentinel標記爲主觀下線.

若是一個Master被標記爲主觀下線，則正在監視這個Master的全部Sentinel都會以每秒一次的頻率確認這個Master的確進入了主觀下線狀態.

當有足夠數量的Sentinel(大於等於配置文件中指定的值)在指定的時間範圍內確認這個Master的確進入了主觀下線狀態，那麼這個Master會被標記爲客觀下線.

在通常狀況下，每一個Sentinel會以每10秒一次的頻率向它已知的全部Master、Slave發送INFO命令.

當有Master被Sentinel標記爲客觀下線時，Sentinel向下線的Master的全部Slave發送INFO命令的頻率會從10秒一次改成每秒一次.

若沒有足夠數量的Sentinel贊成Master已經下線，則此Master的客觀下線狀態就會被移除.

---

主觀下線和客觀下線

主觀下線
Subjectively Down，簡稱SDOWN，指的是當前Sentinel實例對某個redis服務器作出的下線判斷

客觀下線
Objectively Down，簡稱ODOWN，指的是多個Sentinel實例在對Master Server作出SDOWN判斷，而且經過SENTINEL is-master-down-by-addr命令互相交流以後，得出的Master Server下線判斷，而後開啓failover.

SDOWN
適合於Master和Slave，只要一個Sentinel發現Master進入了ODOWN，這個Sentinel就可能會被其它Sentinel推選出，並對下線的主服務器執行自動故障遷移操做.

ODOWN
只適用於Master，對於Slave的Redis實例，Sentinel在將它們判斷爲下線前不須要進行協商，因此Slave的Sentinel永遠不會到達ODOWN.

主從複製架構圖

Redis Sentinel架構圖

Sentinel是redis一個進程，不存儲數據，只負責監控redis.

關於Redis的發佈訂閱，詳見此文獻【Redis發佈訂閱】

---

開始配置主從複製

搭建環境：
一臺Redis服務器（版本redis-5.0.2）
三個Redis實例（一個主節點Master，兩個從節點Slave）

配置文件

---

主節點 7001.conf

port 7001
daemonize yes
logfile /usr/local/redis-5.0.2/logs/7001.log
dbfilename dump-7001.rdb
dir /usr/local/redis-5.0.2/db/7001/

從節點 7002.conf

port 7002
daemonize yes
logfile /usr/local/redis-5.0.2/logs/7002.log
dbfilename dump-7002.rdb
dir /usr/local/redis-5.0.2/db/7002/

# 指定主節點
slaveof 127.0.0.1 7001

從節點 7003.conf

port 7003
daemonize yes
logfile /usr/local/redis-5.0.2/logs/7003.log
dbfilename dump-7003.rdb
dir /usr/local/redis-5.0.2/db/7003/

# 指定主節點
slaveof 127.0.0.1 7001

驗證主從關係

---

在主節點上查看主從通訊關係



在從節點上查看主從通訊關係

此時，一主雙從已經搭建完畢了，可在Master上寫入些數據，而後在Slave查看.

---

開始配置Redis Sentinel

搭建環境：
包含上面搭建主從的全部環境
還增長了三個redis-sentinel實例（27001.conf、27002.conf、27003.conf）

配置文件

---

27001.conf

port 27001
daemonize yes
dir "/usr/local/redis-5.0.2/db/"
logfile "/usr/local/redis-5.0.2/logs/27001.conf"

sentinel monitor mymaster 127.0.0.1 7001 2
# mymaster：主節點的別名
# 當前Sentinel節點監控 127.0.0.1 7001 這個主節點
# 2：表示主節點失敗至少須要2個Sentinel節點贊成

sentinel down-after-milliseconds mymaster 30000
# 每一個Sentinel節點都要按期發PING命令來判斷Redis數據節點和其他Sentinel節點是否可達
# 這裏配置爲30000毫秒，即超過30秒未收到某個節點的PING命令且未收到回覆，則斷定不可達

sentinel parallel-syncs mymaster 1
# 當Sentinel節點集合對主節點故障斷定達成一致時，Sentinel領導者節點會作故障轉移操做，選出新的主節點
# 原來的從節點會向新的主節點發起復制操做，限制每次向新的主節點發起復制操做的從節點個數爲1

sentinel failover-timeout mymaster 180000
# 設定故障轉移的超時時間爲180000毫秒

27002.conf、27003.conf的配置與上面的配置(27001.conf)差別僅在於端口.
啓動哨兵：redis-sentinel 配置文件
啓動後，哨兵的配置文件會被重寫入sentinel myid等信息.

驗證哨兵集羣

---

[root@fedora conf]# redis-cli -p 27001 info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:7003,slaves=2,sentinels=3
# 看到最後一條信息即正確配置了哨兵集羣
# name=mymaster  -> 哨兵別名
# status=ok  -> 狀態OK
# address=127.0.0.1:7003  -> 監控的地址
# slaves=2 -> 當前有2個從節點
# sentinels=3  -> 當前共有3個哨兵

到這裏，哨兵集羣已經搭建完畢了.
不用說，此時你確定是想去幹掉主節點了吧，先別慌，咱們來看看下面的監控擴撲圖.

監控擴撲圖

驗證故障轉移的大體思路

• 幹掉主節點的Redis進程7001端口，等待down-after-milliseconds配置的時間後，觀察從節點是否會進行新的master選舉，進行切換.
• 從新恢復舊的「master」節點，查看此時的redis身份.