redis主從復制、哨兵機制底層原理

寫在前面

redis作為一款高速緩存數據庫，在解決系統速度問題上有頗大的成就， 那么今天就帶大家了解下redis底層都做了哪些事情，本文章需要你有一定的redis基礎，適合想要更深入了解redis底層機制的同學，如果你在過程中有不懂得地方，歡迎在評論區提問！在下一定知無不言；

注意事項

默認情況下，從節點不允許寫操作，只能從主節點同步數據過來；可在配置文件中配置為可寫的操作

主從復制配置和啟動

先啟動三個redis，分別為6379、6380、6381端口，其中6379為主節點,其他2個redis跟隨6379；

啟動主節點

./redis-server /etc/redis/6379.conf

1

啟動6380從節點，啟動后需要追隨主節點， 追隨有3種方式

啟動redis時追隨，–后面的跟隨命令也可以在登錄reids后在命令行執行

# 5.0版本以前 , slaveof 表示跟隨的節點，后面2個參數是ip和端口 ./redis-server /etc/redis/6380.conf --slaveof 127.0.0.1 6379 # 5.0版本以后，replicaof 表示跟隨的節點，后面2個參數是ip和端口 ./redis-server /etc/redis/6380.conf --replicaof 127.0.0.1 6379

1

2

3

4

5

在命令行追隨，啟動redisserver端后，使用redis-cli客戶端連接服務端，輸入以下命令即可

replicaof 127.0.0.1 6379

1

在配置文件種追隨，找到對應節點的 conf配置文件，找到以下配置，replicaof默認是被注釋的，放開注釋并加上ip和端口即可；

replicaof 127.0.0.1 6379

1

啟動6381從節點，–后面的跟隨命令也可以在登錄reids后在命令行執行

# 5.0版本以后，replicaof 表示跟隨的節點，后面2個參數是ip和端口 ./redis-server /etc/redis/6381.conf --replicaof 127.0.0.1 6379

1

2

首次跟隨主節點時，會先將從節點的數據全部刪除，在將主節點的數據同步到從節點；并且，默認情況下從節點就只能讀取，不能在寫入，如果需要寫入，可在配置文件中修改以下選項改為no即可;默認為yes（只讀）

# 只讀模式，默認開啟 replica-read-only yes;

1

2

不想跟隨別人了，自己當老大

當reids的從節點不像追隨某個主節點了，想要自己當主節點，輸入以下命令即可；

replicaof no one

1

主從同步方式

有2種方式同步數據

默認第一種是先將數據以RDB方式持久化到主節點磁盤，然后通過網絡將rdb文件傳到從節點

第二種是直接用網絡的方式將數據傳輸到從節點；

同步方式可通過以下方式進行配置

# 默認 no 為磁盤同步，改為yes則直連同步 repl-diskless-sync no

1

2

增量同步

從節點第一次跟隨主節點時會同步主節點的全量數據， 當主節點修改了數據，這些修改后的數據需要同步到從節點種，不可能每次修改都全量同步，數據量太大的話花費的時候就很長，這時候就需用到增量同步了，主節點內部維護了一個隊列，隊列里面存儲都是修改的命令，隊列里面有一個offset（偏移量），告訴你數據修改到哪了，這個隊列默認大小為1MB，如果隊列里面的數據大于1MB了，就會觸發全量同步；

哨兵機制 sentinel

redis的哨兵機制是用來實現高可用的，也就是當直節點掛掉之后，哨兵進程會在從節點中選出一個節點晉升為主節點；從而保證redis高可用；

啟動哨兵進程

因為哨兵是一個進程，是需要占用端口的，所以在啟動哨兵前，需要先對哨兵進行配置，哨兵配置時只要配置對主節點的監控即可，新建一個文件 26379.conf，內容如下

port 26379 # monitor表示定期監控哨兵節點， # mymaster是哨兵的名稱，名字隨便起，因為哨兵也是集群的，所以集群下每個哨兵進程的名稱也是一樣的；這樣就可以做到一套哨兵控制多套主從復制集群； # 127.0.0.1 6379 是主節點的ip和端口 # 最后的2 是，表示的是哨兵判斷主節點是否發生故障的票數。也就是說如果我們將設置為2就代表至少要有兩個哨兵認為主節點故障了，才算這個主節點是客觀下線的了，一般是設置為sentinel節點數的一半加一。 sentinel monitor mymaster 127.0.0.1 6379 2

1

2

3

4

5

6

7

啟動哨兵，啟動前必須先啟動redis主節點

# --sentinel表示以哨兵機制啟動 redis-server ./26379.conf --sentinel

1

2

啟動后，哨兵進程會修改 26379.conf 配置文件，熱別是當主節點宕機后，會將26379.conf配置文件里面的主節點ip和端口都更換成新的主節點ip端口；并會附帶一些其他信息；

哨兵機制的底層原理

A、監控任務

在哨兵內部有三個定時監控任務，用來實時監控哨兵進程和redis進程

1、每10秒發一次info到主從節點

每個哨兵節點每10秒會向主節點和從節點發送info命令獲取最新拓撲結構圖，哨兵配置時只要配置對主節點的監控即可(sentinel monitor mymaster 127.0.0.1 26379 2)，通過向主節點發送info，獲取從節點的信息，并當有新的從節點加入時可以馬上感知到；

2、每2秒發送一次各節點的信息給主節點

每個哨兵節點每隔2秒會向redis數據節點的指定頻道上發送該哨兵節點對于主節點的判斷以及當前哨兵節點的信息，同時每個哨兵節點也會訂閱該頻道，來了解其它哨兵節點的信息及對主節點的判斷，其實就是通過消息publish和subscribe來完成的；

3、每隔1秒發送一次心跳

每隔1秒每個哨兵會向主節點、從節點及其余哨兵節點發送一次ping命令做一次心跳檢測，這個也是哨兵用來判斷節點是否正常的重要依據；

B、哨兵選舉領導過程（Paxos算法）

redis選主過程使用了非常強大的Paxos算法，因為強大，所以它的內部實現非常復雜，以下介紹Paxos算法的大致流程；

哨兵和redis一樣，也有主從節點，哨兵的主節點叫做領導者，當領導者掛了、或者產生故障了，可能是網絡原因，也可能是程序自身原因；導致主節點不可用了；首先會在在線中的哨兵節點中選出一個領導者，每個在線的哨兵節點都可以成為領導者；

當普通的哨兵節點(哨兵1)發現領導者節點不可用時，會向其他的哨兵節點發送is-master-down-by-addr命令，征求判斷并要求將自己設置為領導者，由領導者處理故障轉移；

當其它哨兵收到此命令時，可以同意或者拒絕它成為領導者；

如果哨兵1發現自己在選舉的票數大于等于num(sentinels)/2+1時，將成為領導者，如果沒有超過，繼續選舉；

選舉出領導者后，后續redis的主節點出現故障時，就由領導者負責故障轉移；

C、主管宕機和客觀宕機

sdown，即主觀宕機，如果一個哨兵它自己覺得master宕機了，就是主觀宕機

odown，即客觀宕機，如果quorum數量的哨兵都認為一個master宕機了，則為客觀宕機

sentinel會以每秒一次的頻率向所有與其建立了命令連接的實例（master，從服務，其他sentinel）發ping命令，通過判斷ping回復是：有效回復、還是無效回復來判斷實例是否在線（對該sentinel來說是“主觀在線”）

sentinel配置文件中的down-after-milliseconds設置了判斷主觀下線的時間長度，如果實例在down-after-milliseconds毫秒內，返回的都是無效回復，那么sentinel回認為該實例已（主觀）下線，修改其flags狀態為SRI_S_DOWN

如果一個哨兵在指定時間內，收到了quorum指定數量的其他哨兵也認為那個master是sdown了，那么就認為是odown了，客觀認為master宕機，就完成了sdown到odown的轉換。

D、redis選主過程—從節點升級為主節點的選舉算法

當redis主節點被認為不可用時，哨兵的領導者會按照如下規則在從節點中選出新的主節點；

只選擇健康的從節點，過濾掉主觀下線的節點

選擇slave-priority最高的節點；有則返回，沒有則繼續下一步；

選擇出復制偏移量最大的系節點，因為復制便宜量越大則數據復制的越完整，如果有就返回，沒有就繼續下一步；

選擇run_id最小的節點；

完

Redis 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。