今晚是除夕夜，我還在整理文檔，真是位可愛又認真的小仙女呀。
之前我們學習了redis的主從復制，效果非常好，能夠分擔主服務器的壓力，提高redis的整體吞吐量。（嗯，雖然“吞吐量”這個詞可能不太恰當）
但是在這個過程中也存在一些問題，比如如果主節點突然掛了，該怎么辦呢？
當然是需要人工干預啦。我們可以在其他從節點中手動選擇一個新的主節點，然后讓其他節點成為這個新主節點的從節點。
具體步驟如下：
1.啟動從節點為主節點。命令為slaveof no one。
2.舊主節點的其他從節點變成新主節點的從節點。命令為slaveof new master。
3.通知應用方Redis主節點已經變更，修改客戶端調用的地址并重啟客戶端。
4.當已經掛掉的主節點重新上線后，舊主節點變成新主節點的從節點。命令為slaveof new master。
請原諒我手機的畫質，因為窮，沒有其他原因啦。
但這都是人工操作的，大家都知道，程序員都很懶，能自動監控的，絕不自己動手。
所以接下來我們要學習Redis的哨兵，也就是自動切換，無需自己動手。
在windows上搭建哨兵
上次主從復制因為懶，沒有寫具體過程，這次得一次還清。所以哦，不要拖延，及時完成任務，不然拖到最后還是得自己干。
今天我們先下載Windows版本的Redis，再搭建主從復制（一主二從），最后搭建監控Redis的哨兵（三個，這里為什么要3個，后面會解釋的，所以啊，我們不急，慢慢來，因為這是一塊大骨頭）。
1.下載Windows版本的Redis
因為Redis官方并不支持Windows，所以我們去gitHub下載，https://www.php.cn/link/ecd610837c2670b1acbe1d57821055b8
2.搭建主從復制（一主二從）
將redis.windows.conf重命名為redis6379.conf，然后復制兩個分別為redis6380.conf，redis6381.conf。
redis6380的配置文件為：
port 6380 bind 127.0.0.1 slaveof 127.0.0.1 6379
redis6381的配置文件為：
port 6381 bind 127.0.0.1 slaveof 127.0.0.1 6379
這些配置文件的意思非常明確，如果不明白，可能得挨打了。
port為當前Redis的端口號。
bind為綁定的服務器。
slaveof為該從服務器跟隨哪個主服務器及其端口號。
配置文件準備好后，就可以啟動它們了。
如下啟動其他兩個從服務器，具體操作就交給你們啦。
三個都啟動完畢后，我們來看一下主節點的狀態，很明顯，6379為主節點，下面有兩個從節點，分別是6380和6381。
3.搭建哨兵（3個）
主從復制搭建好后，我們來搭建哨兵。
新建三個哨兵配置文件：
這些配置文件的含義是什么呢？
port為當前哨兵服務運行的端口。
sentinel monitor mymaster 127.0.0.1 6379 2為哨兵監視一個名為mymaster的主Redis實例，這個主實例的IP地址為127.0.0.1，端口號為6379。
sentinel down-after-milliseconds mymaster 5000為自動失效時間。
sentinel parallel-syncs mymaster 1為指定執行故障轉移時，最多可以有幾個從Redis實例在同步新的主實例。
sentinel failover-timeout mymaster 15000為如果在該時間內未完成節點切換，則認為失敗。
接下來我們來分別啟動三個哨兵：（照貓畫虎）
4.測試哨兵
如果此時我再啟動6239服務器，它是重新成為主節點，還是成為新節點6381的從節點？結論是它成為了從節點。
哨兵進行故障轉移的過程
哨兵Sentinel初始化的過程
步驟如下：
1.初始化服務器（哨兵也是一個正常的Redis服務器）
2.將普通的Redis使用的代碼替換為哨兵Sentinel專用代碼
不需要RDB/AOF文件（因為不需要加載數據，它是監控節點，而不是數據節點）
端口號不一樣（哨兵的端口號為26379，而默認的Redis端口為6379）
普通Redis命令：set/get/dbsize
哨兵命令：ping/sentinel
3.初始化哨兵狀態sentinel
4.向Redis服務器創建連接
一個命令連接：向主服務器發送命令，并接受回復
一個訂閱連接：_sentinel_:hello頻道
在發送與訂閱功能中，被發送的消息不會保存在服務器中。當客戶端不在線/斷線中，為了不丟失這條消息，Redis就用了一個訂閱頻道來接受這條消息。
為什么哨兵是3個？
哨兵集群必須部署兩個以上節點，如果哨兵集群僅僅部署了兩個哨兵實例，那么他的大多數為2（2的大多數為2，3的大多數為2，5的大多數為3，4的大多數為2），如果其中一個哨兵宕機，就無法滿足大多數大于等于2，那么在master發生故障的時候就無法進行主從切換。
哨兵如何監控？
檢測實例是否下線：
主觀下線：哨兵與服務器斷開時間超過指定時間
客觀下線：客觀下線數量超過半數
整個故障轉移流程
1.哨兵領導節點的選舉
相互發送信息：要求對方設置自己為局部零頭哨兵
Raft算法 先到先得 Leader只是故障轉移中出現的角色
可參考：https://www.php.cn/link/f230954603f7a3eea4a0884c786f1ae2
2.新的主服務器怎么選？
由領導節點將所有的從服務器保存在列表中，然后一項項過濾
A.去除所有處于下線的
B.去除近5s內沒有回復的
C.優先級+復制偏移量最大（要求數據為最新的）
D.排序，選擇運行ID最小的。
