高可用基礎---主從復制

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 ：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限制等保護機制，否則是極度危險的。）

哨兵模式的優點

• 哨兵集群、基于主從復制模式，所有的主從復制優點，它會有
• 主從可以切換，故障可以轉移，系統的可用性會更好
• 哨兵模式就是主從模式的升級，手動轉自動，更加健壯

哨兵模式的缺點

• Redis不好在線擴展，集群容量一旦到達上限，在線擴容十分麻煩
• 實現哨兵模式的配置很麻煩，里面有很多選擇