、主從復制高可用
#主從復制存在的問題： 1 主從復制，主節點發生故障，需要做故障轉移，可以手動轉移：讓其中一個slave變成master 2 主從復制，只能主寫數據，所以寫能力和存儲能力有限
哨兵是對Redis的系統的運行情況的監控，它是一個獨立進程，它會獨立運行，功能有二個：
-
通過發送命令，讓Redis服務器返回監控其運行狀態，包括主服務器和從服務器。
-
當哨兵監測到master宕機，會自動將slave切換成master，然后通過發布訂閱模式通知其他的從服務器，修改配置文件，讓它們切換主機。
二、架構說明
可以做故障判斷，故障轉移，通知客戶端（其實是一個進程），客戶端直接連接sentinel的地址
流程
1 多個sentinel發現並確認master有問題 2 選舉觸一個sentinel作為領導 3 選取一個slave作為新的master 4 通知其余slave成為新的master的slave 5 通知客戶端主從變化 6 等待老的master復活成為新master的slave
三、配置哨兵
一般配置多個哨兵，除了監控各個redis服務器之外，哨兵之間也會互相監控。
1.環境配置
| 主機服務 | 主機IP | 端口 | sentinel端口 |
| master（主庫） | 127.0.0.1
|
6379 |
26379 |
| slave （從庫） | 127.0.0.1 | 6380 | 26380 |
| slave （從庫） | 127.0.0.1 |
6381
|
26381 |
redis默認的sentinel.conf文件
2.創建自定義sentinel文件
進入服務器的redis文件夾下，創建redis6379_sentinel.conf配置
port 26379 #此端口號是該哨兵文件的端口號，每個哨兵文件的端口號不同 daemonize no dir /root/data protected-mode no bind 0.0.0.0 logfile "redis6379_sentinel.log"
#sentinel monitor代表監控，mymaster是給主庫取得別名，ip地址代表監控的主庫，6379是主庫的端口號，2代表有兩個或者兩個以上的哨兵認為主庫不可用時，才會進行換庫 sentinel monitor mymaster 127.0.0.1 6379 2
#此配置指需要多少時間，一個master才會被sentinel主觀認定是不可用的，單位是毫秒，默認是30秒 sentinel down-after-milliseconds mymaster 30000
#此配置值在發生故障時，最多可以有幾個slave同時對新的master進行同步，這個數字越小完成故障處理的時間越短 sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
#failover-timeout可以用在以下這些方面
#1. 同一個sentinel對同一個master兩次failover之間的間隔時間。 #2. 當一個slave從一個錯誤的master那里同步數據開始計算時間。直到slave被糾正為向正確的master那里同步數據時。 #3.當想要取消一個正在進行的failover所需要的時間。 #4.當進行failover時，配置所有slaves指向新的master所需的最大時間。不過，即使過了這個超時，slaves依然會被正確配置為指向master，但是就不按parallel-syncs所配置的規則來了。
需要三個哨兵，所以創建三個sentinel.conf
redis6380_sentinel.conf
注意：需要將端口號改為26380（******）
同理，再復制出一份redis6381_sentinel.conf,這樣就完成了三個哨兵的配置
四、啟動哨兵
1.首先需要先把redis的主從服務器啟動：redis-server redis.conf
2.然后啟動3個哨兵:redis-sentinel sentinel.conf
3.查看sentinel信息
啟動之后可以看到redis6381_sentinel.conf配置有一些添加的內容
如果發生了故障，sentinel的配置文件會自動進行相應的更改。
客戶端連接:redis-cli -p 26379,再輸入info查看到的部分信息
# Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0
#主節點是mymaster,ip和端口是127.0.0.1和6379,有2個從節點，4個哨兵 master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=4
這樣就是配置成功了
五、python中使用哨兵模式
import redis from redis.sentinel import Sentinel # 連接哨兵服務器(主機名也可以用域名) # 101.132.167.242是遠程服務器的ip地址 sentinel = Sentinel([('101.132.167.242', 26379), ('101.132.167.242', 26380), ('101.132.167.242', 26381) ], socket_timeout=5) print(sentinel) #Sentinel<sentinels=[101.132.167.242:26379,101.132.167.242:26380,101.132.167.242:26381]> # 獲取主服務器地址 master = sentinel.discover_master('mymaster') print(master) #('127.0.0.1', 6379) # 獲取從服務器地址 slave = sentinel.discover_slaves('mymaster') print(slave) #[('127.0.0.1', 6380), ('127.0.0.1', 6381)] # 獲取主服務器進行寫入 master = sentinel.master_for('mymaster', socket_timeout=0.5) #獲取主服務器，往里面寫入值 w_ret = master.set('foo', 'bar') slave = sentinel.slave_for('mymaster', socket_timeout=0.5) #獲取從服務器，往里面獲取值 r_ret = slave.get('foo') print(r_ret)
出現這種錯誤，可能是阿里雲沒設置哨兵端口號
在阿里雲中設置哨兵端口號
出現time out報錯可能是因為代碼中timeout時間設置太短了
時間設置長一點就行
六、主服務故障轉移
1.先關閉主服務器redis,過一會查看一下sentinel日志。
2.查看26379 sentinel文件
15637:X 12 Jan 2020 21:44:38.983 # +sdown master mymaster 127.0.0.1 6379 #發現master服務已經不能用 15637:X 12 Jan 2020 21:44:39.063 # +new-epoch 1 15637:X 12 Jan 2020 21:44:39.065 # +vote-for-leader c8391221c81f7c2b0c0ed04bb7de6ae84a8f7afd 1 #投票選舉哪個哨兵當leader 15637:X 12 Jan 2020 21:44:39.066 # +odown master mymaster 127.0.0.1 6379 #quorum 3/2 #3個哨兵有2哨兵投票不能使用了 15637:X 12 Jan 2020 21:44:39.066 # Next failover delay: I will not start a failover before Sun Jan 12 21:50:40 2020 15637:X 12 Jan 2020 21:44:40.066 # +config-update-from sentinel c8391221c81f7c2b0c0ed04bb7de6ae84a8f7afd 127.0.0.1 26381 @ mymaster 127.0.0.1 6379
#26381哨兵當leader修改配置，6381升級為master 15637:X 12 Jan 2020 21:44:40.066 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6381 #主數據庫從6379轉變為6381 15637:X 12 Jan 2020 21:44:40.066 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381 #添加6380為6381的從庫 15637:X 12 Jan 2020 21:44:40.066 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381 #添加6379為6381的從庫 15637:X 12 Jan 2020 21:45:10.088 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381 #發現6379已經宕機，等待6379的恢復
3.客戶端連接查看主服務器轉移
客戶端連接6381，輸入info replication
可以看出，6381目前是master,擁有一個slave,slave是6380
客戶端連接6380，輸入info replication
可以看出6380是slave,master是6381
4.重新啟動6379查看狀態
啟動6379：
客戶端連接6381查看狀態：
已經將6379設置為6381的slave
查看6379 sentine.log文件
15637:X 12 Jan 2020 23:47:40.287 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381 #6379已經恢復服務 15637:X 12 Jan 2020 23:47:50.234 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381 #將6379設置為6381的slave
七、從服務故障轉移
關閉6380從服務
查看6380 sentinel.log文件
說明已經監控到6380slave宕機了，那么如果恢復6380端口服務，會自動加入到主從復制嗎？
從6381的客戶端也可以查出6380宕機了，slave數量變為1
重新啟動6380從服務，查看6380 sentinel.log文件
可以看出6380slave新加入了主從復制中，-sdown:說明是恢復服務