【資料庫】Redis(6)--Redis主從復制

1.1.Redis主從復制概念

概念

主從復制，是指將一臺Redis服務器的資料，復制到其它的Redis服務器，前者稱為主節點(master/leader)，后者稱為從節點(slave/follower)；資料的復制是單向的，只能由主節點到從節點，Master以寫為主，Slave以讀為主，

默認情況下，每臺Redis服務器都是主節點；且一個主節點可以有多個從節點（或沒有從節點），但一個從節點只能有一個主節點，

主從復制的作用主要包括：

1.資料冗余：主從復制實作了資料的熱備份，是持久化之外的一種資料冗余方式，

2.故障恢復：當主節點出現問題時，可以由從節點提供服務，實作快速的故障恢復；實際上是一種服務的冗余，

3.負載均衡：在主從復制的基礎上，配合讀寫分離，可以由主節點提供寫服務，由從節點提供讀服務（即寫Redis資料時應用連接主節點，讀Redis資料時應用連接從節點），分擔服務器負載；尤其是在寫少讀多的場景下，通過多個節點分擔讀寫負載，可以大大提高Redis服務器的并發量，

4.高可用基石：除了上述作用以外，主從復制還是哨兵和集群能夠實施的基礎，因此說主從復制是Redis高可用的基礎，

一般來說，要將Redis運用于工程專案中，只使用一臺Redis是萬萬不能的，原因如下：

1.從結構上，單個Redis服務器會發生單點故障，并且一臺服務器需要處理所有的請求負載，壓力較大；

2.從容量上，單個Redis服務器記憶體容量有限，就算一臺Redis服務器記憶體容量為256G，也不能將所有記憶體用作Redis存盤記憶體，一般來說，單臺Redis最大使用記憶體不應該超過20G；

 主從復制，讀寫分離，80%的情況下都是在進行讀操作，級訓服務器的壓力，架構中經常使用，一主二從，

1.2.環境配置

Redis默認單機啟動之后就是master，主從復制只需要配置從庫，不用配置主庫，

127.0.0.1:6379> info replication  #查看當前庫的資訊
# Replication
role:master  #顯示當前server的角色  master
connected_slaves:0  # 顯示從機的個數
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

這里實際專案中都是部署在同一網段的不同服務器上，這里只做簡單說明配置，需要在另外的服務器上去創建兩個從機Redis slave從機，具體需要修改的是redis.conf檔案中的如下配置：

port 6379 #埠號
logfile "6379.log" #log日志檔案存放位置
dbfilename dump6379.rdb  #redis持久化存放目錄

其它從機的redis.conf檔案配置一致即可，

1.3.配置一主二從

默認情況下，每臺Redis服務器都是主節點；我們一般情況下只用配置從機就可以了，

認老大，就是一臺作為主機（79）二臺作為從機（80/81）

具體配置如下：

127.0.0.1:6380> SLAVEOF 127.0.0.1:6379 #手動使用命令方式選擇6379作為自己的老大
OK
127.0.0.1:6380> info relication
# Replication
role:slave  #當前角色是從機
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:14
slave_read_only:1
connected_slaves:0

對應主機端可以看到從機的狀態如下：

真實的主從配置應該是在組態檔中配置，這樣的話是永久的，這里使用slaveof命令只是暫時的，

在redis.conf檔案中我們需要配置replicaof，設定masterip地址和埠號；如果主機有密碼，那么配置matserauth 對應的密碼即可，

 細節

主從配置默認是主機可以寫，從機不能寫只能讀取，主機中的所有資訊和資料，都會被從機保存，

即在從機中只能讀取到主機中設定的key的值，而不能進行set key值操作，

如果是使用命令列，來配置的主從，這個時候如果重啟了，就會便會主機，只要變為從機，立馬就會從主機中獲取值，

原理

Slave啟動成功連接到master后會發送一個sync同步命令

Master接到命令，啟動后臺的存盤行程，同時收集所有收到的用于修改資料集命令，在后臺行程執行完畢之后，master將傳送整個資料檔案到slave，并完成一次同步，

全量復制：slave服務在接收到資料庫檔案資料后，將其存盤并加載到記憶體中；

增量復制：master繼續將新的所有收集到的修改命令依次傳給slave，完成同步，

但是只要是重新連接master，一次完全同步（全量復制）將被自動執行，我們的資料一定可以在從機中看到，

手動版謀朝篡位

如果主機斷開了連接，我們可以使用SLAVE no one命令，讓自己變成主機，其它的節點就可以手動連接到最新的這個主節點（手動版），如果這個時候老大修復了，那就重新連接，

1.4.Redis哨兵模式

簡單地說Redis哨兵模式，就是自動選舉老大的模式，

概述

主從切換技術的方法是：當主服務器宕機后，需要手動把一臺服務器切換為主服務器，這就需要人工干預，費事費力，還會造成一段時間內服務不可用，這不是一種推薦的方式，更多時候，我們優先考慮哨兵模式，Redis從2.8開始正式提供了Sentinel（哨兵）架構來解決這個問題，

謀朝篡位的自動版，能夠后臺監控主機是否故障，如果故障了根據投票數自動將從庫換成主庫，

哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的行程，作為行程，它會獨立運行，其原理是哨兵通過發送命令，等待Redis服務器回應，從而監控運行的多個Redis實體，

這里哨兵有兩個作用：

• 通過發送命令，讓Redis服務器回傳監控其運行狀態，包括主服務器和從服務器，

• 當哨兵監測到master宕機，會自動將slave切換成master，然后通過發布訂閱模式通知其它的從服務器，修改組態檔，讓它們切換主機，

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

 假設主服務器宕機，哨兵1先檢測到這個結果，系統并不會馬上進行failover程序，僅僅是哨兵1主觀的認為主服務器不可用，這個現象稱為主觀下線，當后面的哨兵也檢測到主服務器不可用，并且數量達到一定值時，那么哨兵之間就會進行一次投票，投票的結果由一個哨兵發起，進行failover[故障轉移]操作，切換成功后，就會通過發布訂閱模式，讓各個哨兵把自己監控的從服務器實作切換主機，這個程序稱為客觀下線，

測驗

我們目前的狀態是一主二從

1.配置哨兵組態檔sentinel.conf

# sentinel monitor 被監控的名稱 host port 1
sentinel monitor myredis 127.0.0.1 6379 1

后面的數字1，代表主機掛了，slave投票看讓誰接替成為主機，票數最多的，就會成為主機，

2.啟動哨兵

[root@fengye bin]# redis-sentinel fconfig/sentinel.conf

如果Master節點斷開了，這個時候就會從從機中隨機選擇一個服務器（這里面有一個投票演算法），

這里如果主機此時回來了，只能歸并到新的主機下，當做從機，這就是哨兵模式的規則，

哨兵模式

優點：

1.哨兵集群，基于主從復制模式，所有的主從配置優點，它全有，

2.主從可以切換，故障可以轉移，系統的可用性就會更好，

3.哨兵模式就是主從模式的升級，手動到自動，更加健壯，

缺點：

1.Redis不好在線擴容的，集群容量一旦達到上限，在線擴容就十分麻煩，

2.實作哨兵模式的配置其實是很麻煩的，里面有很多選擇，

1.5.哨兵模式配置

哨兵模式的全部配置

# Example sentinel.conf

# 哨兵sentinel實體運行的埠 默認26379，如果有哨兵集群，還需要配置每個哨兵埠
port 26379

# 哨兵sentinel的作業目錄
dir /tmp

# 哨兵sentinel監控的redis主節點的 ip port
# master-name 可以自己命名的主節點名字 只能由字母A-Z、數字0-9、這三個字符".-_"組成，
# quorum配置多少個sentinel哨兵統一認為master主節點失聯，那么這時客觀上認為主節點失聯了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

# 當在Redis實體中開啟了requirepass foobared 授權密碼，這樣所有連接Redis實體的客戶端都是需要提供密碼
# 設定哨兵sentinel，連接主從的密碼，注意必須為主從設定一樣的驗證密碼
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MYSUPER--secret-0123passw0rd

# 指定多少毫秒之后，主節點沒有應答哨兵sentinel，此時，哨兵主觀上認為主節點下線，默認30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymatser 30000

# 這個配置項指定了在發生failover主備切換時最多可以有多少個slave同時對新的master進行同步
這個數字越小，完成failover所需的時間就越長，但是如果這個數字越大，越意味著越多的slave因為replication而不可用，可以通過將這個值設為1來保證每次只有一個slave處于不能處理命名請求的狀態，
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1

# 故障轉移的超時時間，failover-timeout，可以用在以下這些方面：
# 1.同一個sentinel對同一個master兩次failover之間的間隔時間
# 2.當一個slave從一個錯誤的master那里同步資料開始計算時間，直到slave被糾正為向正確的master那里同步資料時
# 3.當想要取消一個正在進行的failover所需要的時間
# 4.當進行failover時，配置所有slaves指向新的master所需的最大時間，不過，即使過了這個超時，slaves依然會被正確配置為指向master，但是就不按parallel-syncs所配置的規則來了
# 默認三分鐘
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000

# SCRIPTS EXECUTION

# 配置當某一事件發生時所需要執行的腳本，可以通過腳本來通知管理員，例如當系統運行不正常時發郵件通知相關人員，
# 對于腳本的運行結果有以下規則：
# 若腳本執行后回傳1，那么該腳本稍后將會被再次執行，重復次數目前默認為10
# 若腳本執行后回傳2，或者比2更高的一個回傳值，腳本將不會重復執行
# 如果腳本在執行程序中由于收到系統中斷信號被終止了，則同回傳值為1時的行為相同
# 一個腳本的最大執行時間為60s，如果超過這個時間，腳本將會被一個SIGKILL信號終止，之后重新執行

1).sentinel notification-script <master-name> <script-path> 

# 通知型腳本:當sentinel有任何警告級別的事件發生時（比如說redis實體的主觀失效和客觀失效等等），將會去呼叫這個腳本，這時這個腳本應該通過郵件，SMS等方式去通知系統管理員關于系統不正常運行的資訊，呼叫該腳本時，將傳給腳本兩個引數，一個是事件的型別，一個是事件的描述，如果sentinel.conf組態檔中配置了這個腳本路徑，那么必須保證這個腳本存在于這個路徑，并且是可執行的，否則sentinel無法正常啟動成功，

# 通知腳本
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh

# 客戶端重新配置主節點引數腳本
# 當一個master由于failover而發生改變時，這個腳本將會被呼叫，通知相關的客戶端關于master地址已經發生改變的資訊
# 以下引數將會在呼叫腳本時傳給腳本：
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>總是"failover"
# <role>是"leader"或者"observer"中的一個
# 引數from-ip，from-port，to-ip，to-port是用來和舊的master和新的master(即舊的slave)通信的
# 這個腳本應該是通用的，能被多次呼叫的，不是針對性的
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

標籤：Java

上一篇：一小時,從零實作Java人臉識別功能,opencv

下一篇：初學Python-day7 案例