【Redis哨兵集群】
目錄
- 開始配置主從復制
- 開始配置Redis Sentinel
@
***
在開始之前，我們先來看看Redis的主從復制
主從復制原理：
- 從服務器向主服務器發送
SYNC命令。- 主服務器接到
SYNC命令後，會調用BGSAVE命令，創建一個RDB文件，並使用緩沖區記錄接下來執行的所有寫命令。- 當主服務器執行完
BGSAVE命令後，會向從服務器發送RDB文件，而從服務器則會接收並執行這個文件。- 主服務器將緩沖區存儲的所有寫命令發送給從服務器執行。
---------
Redis主從復制使用的是RDB備份方式來同步主從服務器的數據的。
同步開始之後，通過主庫命令傳播的方式，主動復制方式實現。
2.8以後實現PSYNC餓機制，實現斷線重連。
Redis主從復制的背景問題
Reids主從復制可將主節點數據同步給從節點，從節點此時有兩個作用：
- 一旦主節點宕機，從節點作為主節點的備份可以隨時頂上來.
- 擴展主節點的讀能力，分擔主節點的讀壓力.
.
一旦主節點宕機，從節點上位，那麽就需要人為修改所有應用方的主節點地址（指定新的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.confport 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.confport 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身份.
【Redis哨兵集群】