高可用基礎(chǔ)---主從復(fù)制

Redis的復(fù)制功能是支持將多個數(shù)據(jù)庫之間進行數(shù)據(jù)同步，主數(shù)據(jù)庫可以進行讀寫操作。當主數(shù)據(jù)庫數(shù)據(jù)發(fā)生改變時會自動同步到從數(shù)據(jù)庫，從數(shù)據(jù)庫一般是只讀的，會接收注數(shù)據(jù)庫同步過來的數(shù)據(jù)。

一個主數(shù)據(jù)庫可以有多個從數(shù)據(jù)庫，而一個從數(shù)據(jù)庫只能有一個主數(shù)據(jù)庫，默認情況下，每臺服務(wù)器都是主節(jié)點，可以通過配置來設(shè)置Redis節(jié)點稱為從數(shù)據(jù)庫。

主從復(fù)制的原理

• 當啟動一個從節(jié)點時，它會發(fā)送一個 PSYNC 命令（分為全量復(fù)制和部分復(fù)制）給主節(jié)點；
• 如果是從節(jié)點初次連接到主節(jié)點，那么會觸發(fā)一次全量復(fù)制。此時主節(jié)點會啟動一個后臺線程，開始生成一份 RDB 快照文件；
• 同時還會將從客戶端 client 新收到的所有寫命令緩存在內(nèi)存中。RDB 文件生成完畢后， 主節(jié)點會將RDB文件發(fā)送給從節(jié)點，從節(jié)點會先將RDB文件寫入本地磁盤，然后再從本地磁盤加載到內(nèi)存中；
• 接著主節(jié)點會將內(nèi)存中緩存的寫命令發(fā)送到從節(jié)點，從節(jié)點同步這些數(shù)據(jù)；
• 如果從節(jié)點跟主節(jié)點之間網(wǎng)絡(luò)出現(xiàn)故障，連接斷開了，會自動重連，連接之后主節(jié)點僅會將部分缺失的數(shù)據(jù)同步給從節(jié)點。

主從復(fù)制配置

默認情況下，每個節(jié)點都是主節(jié)點，只需要配置從節(jié)點。可以通過復(fù)制Redis.conf配置文件，修改主要信息，例如：端口號、pid名稱、log文件名稱、dump.rdb名稱等，可以修改配置，配置就永久有效，也可以通過命令形式做處理。

命令：info replication:查看當前庫信息

命令：slaveof ip port :在從服務(wù)器上執(zhí)行名，給定主服務(wù)器的端口和IP

命令：Slave no one :可以讓從節(jié)點恢復(fù)為主機

示例

啟動三個Redis服務(wù)，給定端口6380、6381、6382。給定6380為主節(jié)點

1、創(chuàng)建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、連接數(shù)據(jù)庫并設(shè)置主從復(fù)制

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

主從配置完成后，主節(jié)點信息：

從節(jié)點信息：

數(shù)據(jù)同步測試：

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

搭建好的主從復(fù)制方案可以達到數(shù)據(jù)同步目的，但是當主服務(wù)器宕機后，需要手動將一個從服務(wù)器切換為主服務(wù)器，這個過程需要人工干預(yù)，同時切換會導(dǎo)致Redis的寫入功能不可用。需要一種能夠自動完成master故障發(fā)現(xiàn)并能夠?qū)⒁粋€Slave切換為master，這個時候需要哨兵sentinel模式，哨兵模式可以自動切換主從節(jié)點。

哨兵模式簡介

sentinel是官方提供的高可用方案，其原理是哨兵通過發(fā)送命令，等待Redis服務(wù)器響應(yīng)，從而監(jiān)控運行的多個Redis實例。同時 sentinel是一個分布式系統(tǒng)，可以在一個架構(gòu)中運行多個Sentinel進程。所以監(jiān)控同一個Master的Sentinel會自動連接，組成一個分布式的Sentinel網(wǎng)絡(luò)，互相通信并交換彼此關(guān)于被監(jiān)視服務(wù)器信息。

sentinel工作過程：

• 通過向主服務(wù)器和從服務(wù)器發(fā)送ping命令，讓服務(wù)器返回運行狀態(tài)。
• 當哨兵監(jiān)測到master宕機，會自動將一個slave切換成master，然后通過發(fā)布訂閱模式通知其他的從服務(wù)器，修改配置文件，讓它們切換主機。

關(guān)于sentinel的三個定時任務(wù)：

• 每1秒每個sentinel對其他sentinel和redis節(jié)點執(zhí)行ping操作，心跳檢測。
• 每10秒每個sentinel會對master和slave執(zhí)行info命令，目的是發(fā)現(xiàn)slave結(jié)點，確定主從關(guān)系。
• 每2秒每個sentinel通過master節(jié)點的channel交換信息（pub/sub）。master節(jié)點上有一個發(fā)布訂閱的頻道(sentinel:hello)。sentinel節(jié)點通過sentinel:hello頻道進行信息交換(對節(jié)點的"看法"和自身的信息)，達成共識。

哨兵工作原理

• 每個Sentinel以每秒鐘一次的頻率向它所知道的Master，Slave以及其他 Sentinel實例發(fā)送一個 PING命令。
• 如果一個實例距離最后一次有效回復(fù) PING 命令的時間超過指定值， 則這個實例會被 Sentine 標記為主觀下線。
• 如果一個Master被標記為主觀下線，則正在監(jiān)視這個Master的所有 Sentinel要以每秒一次的頻率確認Master是否真正進入主觀下線狀態(tài)。
• 當有足夠數(shù)量的 Sentinel（大于等于配置文件指定值）在指定的時間范圍內(nèi)確認Master的確進入了主觀下線狀態(tài)， 則Master會被標記為客觀下線 。若沒有足夠數(shù)量的 Sentinel同意 Master 已經(jīng)下線， Master 的客觀下線狀態(tài)就會被解除。若 Master重新向 Sentinel 的 PING 命令返回有效回復(fù)， Master 的主觀下線狀態(tài)就會被移除。
• 哨兵節(jié)點會選舉出哨兵 leader，負責故障轉(zhuǎn)移的工作。
• 哨兵 leader 會推選出某個表現(xiàn)良好的從節(jié)點成為新的主節(jié)點，然后通知其他從節(jié)點更新主節(jié)點信息。

然而一個哨兵進程對Redis服務(wù)器進行監(jiān)控，可能會出現(xiàn)問題，為此，我們可以使用多個哨兵進行監(jiān)控，各個哨兵之間還會進行監(jiān)控，這樣就形成了多哨兵模式。

哨兵故障修復(fù)原理

1.主觀下線：

當主服務(wù)器發(fā)生故障時，此時一個sentinel發(fā)現(xiàn)了故障，系統(tǒng)并不會馬上進行failover過程（這個現(xiàn)象稱為主觀下線），它會向網(wǎng)絡(luò)中的其他Sentinel進行確認。

2.客觀下線：

接著其他Sentinel也陸續(xù)發(fā)現(xiàn)故障，這個時候其中一個Sentinel就會發(fā)起投票。一定數(shù)量的哨兵(在配置文件中指定)確認Master被標記為主觀下線，此時將Master標記為客觀下線。

3.sentinel的leader選舉：

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

4.master選舉：

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

• slave的優(yōu)先級
• slave從master那同步的數(shù)據(jù)量，那個slave多就優(yōu)先。

5.新Master再通過發(fā)布訂閱模式通知所有sentinel更新監(jiān)控主機信息。

6.故障的主服務(wù)器修復(fù)后將成為從服務(wù)器繼續(xù)工作。

示例：故障發(fā)生時：

故障切換：

Master重新上線后：

sentinel.conf配置講解

配置哨兵配置文件 sentinel.conf

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

• name ：redis主服務(wù)名稱，可以自行命名，但是在一個sentinel網(wǎng)絡(luò)中，一個redis主服務(wù)只能有一個名稱；
• ip和port ：redis主服務(wù)的IP地址和端口號.
• quorum ：表示要將這個主服務(wù)器判斷為失效并下線至少需要2個sentinel同意
• protected-mode ：關(guān)閉保護模式（默認情況下，redis node和sentinel的protected-mode都是yes，在搭建集群時，若想從遠程連接redis集群，需要將redis node和sentinel的protected-mode修改為no，若只修改redis node，從遠程連接sentinel后，依然是無法正常使用的，且sentinel的配置文件中沒有protected-mode配置項，需要手工添加。依據(jù)redis文檔的說明，若protected-mode設(shè)置為no后，需要增加密碼證或是IP限制等保護機制，否則是極度危險的。）

哨兵模式的優(yōu)點

• 哨兵集群、基于主從復(fù)制模式，所有的主從復(fù)制優(yōu)點，它會有
• 主從可以切換，故障可以轉(zhuǎn)移，系統(tǒng)的可用性會更好
• 哨兵模式就是主從模式的升級，手動轉(zhuǎn)自動，更加健壯

哨兵模式的缺點

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

到此這篇關(guān)于Redis超詳細講解高可用主從復(fù)制基礎(chǔ)與哨兵模式方案的文章就介紹到這了,更多相關(guān)Redis 高可用內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論