Redis超詳細講解高可用主從複製基礎與哨兵模式方案

2022-04-07 13:03:08

高可用基礎---主從複製

Redis的複製功能是支援將多個資料庫之間進行資料同步，主資料庫可以進行讀寫操作。當主資料庫資料發生改變時會自動同步到從資料庫，從資料庫一般是唯讀的，會接收注資料庫同步過來的資料。

一個主資料庫可以有多個從資料庫，而一個從資料庫只能有一個主資料庫，預設情況下，每臺伺服器都是主節點，可以通過設定來設定Redis節點稱為從資料庫。

主從複製的原理

當啟動一個從節點時，它會傳送一個 PSYNC 命令（分為全量複製和部分複製）給主節點；
如果是從節點初次連線到主節點，那麼會觸發一次全量複製。此時主節點會啟動一個後臺執行緒，開始生成一份 RDB 快照檔案；
同時還會將從使用者端 client 新收到的所有寫命令快取在記憶體中。RDB 檔案生成完畢後，主節點會將RDB檔案傳送給從節點，從節點會先將RDB檔案寫入本地磁碟，然後再從本地磁碟載入到記憶體中；
接著主節點會將記憶體中快取的寫命令傳送到從節點，從節點同步這些資料；
如果從節點跟主節點之間網路出現故障，連線斷開了，會自動重連，連線之後主節點僅會將部分缺失的資料同步給從節點。

主從複製設定

預設情況下，每個節點都是主節點，只需要設定從節點。可以通過複製Redis.conf組態檔，修改主要資訊，例如：埠號、pid名稱、log檔名稱、dump.rdb名稱等，可以修改設定，設定就永久有效，也可以通過命令形式做處理。

命令：info replication:檢視當前庫資訊

命令：slaveof ip port :在從伺服器上執行名，給定主伺服器的埠和IP

命令：Slave no one :可以讓從節點恢復為主機

範例

啟動三個Redis服務，給定埠6380、6381、6382。給定6380為主節點

1、建立Redis範例

nohup redis-server --port 6380 >> /usr/local/redis/data/log/6380.log 2>&1 &
nohup redis-server --port 6381 >> /usr/local/redis/data/log/6381.log 2>&1 &
nohup redis-server --port 6382 >> /usr/local/redis/data/log/6382.log 2>&1 &
 
[root@redis ~]# ps -ef |grep redis
root      16421  16314  0 03:01 pts/1    00:00:00 redis-server *:6380
root      16427  16314  0 03:01 pts/1    00:00:00 redis-server *:6381
root      16431  16314  0 03:01 pts/1    00:00:00 redis-server *:6382

2、連線資料庫並設定主從複製

Gong-Dezhe-MBP:log gongdezhe$ redis-cli -p 6380
127.0.0.1:6380> 

Gong-Dezhe-MBP:~ gongdezhe$ redis-cli -p 6381
127.0.0.1:6381> slaveof 127.0.0.1 6380
OK

Gong-Dezhe-MBP:~ gongdezhe$ redis-cli -p 6382
127.0.0.1:6382> slaveof 127.0.0.1 6380
OK

主從設定完成後，主節點資訊：

從節點資訊：

資料同步測試：

高可用方案---哨兵模式sentinel

搭建好的主從複製方案可以達到資料同步目的，但是當主伺服器宕機後，需要手動將一個從伺服器切換為主伺服器，這個過程需要人工干預，同時切換會導致Redis的寫入功能不可用。需要一種能夠自動完成master故障發現並能夠將一個Slave切換為master，這個時候需要哨兵sentinel模式，哨兵模式可以自動切換主從節點。

哨兵模式簡介

sentinel是官方提供的高可用方案，其原理是哨兵通過傳送命令，等待Redis伺服器響應，從而監控執行的多個Redis範例。同時 sentinel是一個分散式系統，可以在一個架構中執行多個Sentinel程序。所以監控同一個Master的Sentinel會自動連線，組成一個分散式的Sentinel網路，互相通訊並交換彼此關於被監視伺服器資訊。

sentinel工作過程：

通過向主伺服器和從伺服器傳送ping命令，讓伺服器返回執行狀態。
當哨兵監測到master宕機，會自動將一個slave切換成master，然後通過釋出訂閱模式通知其他的從伺服器，修改組態檔，讓它們切換主機。

關於sentinel的三個定時任務：

每1秒每個sentinel對其他sentinel和redis節點執行ping操作，心跳檢測。
每10秒每個sentinel會對master和slave執行info命令，目的是發現slave結點，確定主從關係。
每2秒每個sentinel通過master節點的channel交換資訊（pub/sub）。master節點上有一個釋出訂閱的頻道(sentinel:hello)。sentinel節點通過sentinel:hello頻道進行資訊交換(對節點的"看法"和自身的資訊)，達成共識。

哨兵工作原理

每個Sentinel以每秒鐘一次的頻率向它所知道的Master，Slave以及其他 Sentinel範例傳送一個 PING命令。
如果一個範例距離最後一次有效回覆 PING 命令的時間超過指定值，則這個範例會被 Sentine 標記為主觀下線。
如果一個Master被標記為主觀下線，則正在監視這個Master的所有 Sentinel要以每秒一次的頻率確認Master是否真正進入主觀下線狀態。
當有足夠數量的 Sentinel（大於等於組態檔指定值）在指定的時間範圍內確認Master的確進入了主觀下線狀態，則Master會被標記為客觀下線。若沒有足夠數量的 Sentinel同意 Master 已經下線， Master 的客觀下線狀態就會被解除。若 Master重新向 Sentinel 的 PING 命令返回有效回覆， Master 的主觀下線狀態就會被移除。
哨兵節點會選舉出哨兵 leader，負責故障轉移的工作。
哨兵 leader 會推選出某個表現良好的從節點成為新的主節點，然後通知其他從節點更新主節點資訊。

然而一個哨兵程序對Redis伺服器進行監控，可能會出現問題，為此，我們可以使用多個哨兵進行監控，各個哨兵之間還會進行監控，這樣就形成了多哨兵模式。

哨兵故障修復原理

1.主觀下線：

當主伺服器發生故障時，此時一個sentinel發現了故障，系統並不會馬上進行failover過程（這個現象稱為主觀下線），它會向網路中的其他Sentinel進行確認。

2.客觀下線：

接著其他Sentinel也陸續發現故障，這個時候其中一個Sentinel就會發起投票。一定數量的哨兵(在組態檔中指定)確認Master被標記為主觀下線，此時將Master標記為客觀下線。

3.sentinel的leader選舉：

要想完成故障切換（將故障master剔除，並將一個slave提升為master）就必須先選舉一個leader。最先發現故障的sentinel向其他哨兵發起請求成為leader，其他哨兵在沒有同意別的哨兵的leader請求時，就會把票投給該sentinel。當半數以上的sentinel投票通過後就認定該sentinel為leader。接下來的故障切換有該leader完成。

4.master選舉：

leader選好後將故障master剔除，從slave中挑選一個成為master。遵照的原則如下：

slave的優先順序
slave從master那同步的資料量，那個slave多就優先。

5.新Master再通過釋出訂閱模式通知所有sentinel更新監控主機資訊。

6.故障的主伺服器修復後將成為從伺服器繼續工作。

範例：故障發生時：

故障切換：

Master重新上線後：

sentinel.conf設定講解

設定哨兵組態檔 sentinel.conf

#Sentinel monitor <name> <ip> <port> <quorum>

name ：redis主服務名稱，可以自行命名，但是在一個sentinel網路中，一個redis主服務只能有一個名稱；
ip和port ：redis主服務的IP地址和埠號.
quorum ：表示要將這個主伺服器判斷為失效並下線至少需要2個sentinel同意
protected-mode ：關閉保護模式（預設情況下，redis node和sentinel的protected-mode都是yes，在搭建叢集時，若想從遠端連線redis叢集，需要將redis node和sentinel的protected-mode修改為no，若只修改redis node，從遠端連線sentinel後，依然是無法正常使用的，且sentinel的組態檔中沒有protected-mode設定項，需要手工新增。依據redis檔案的說明，若protected-mode設定為no後，需要增加密碼證或是IP限制等保護機制，否則是極度危險的。）