Redis5.0.4複製

redis的複製很簡單，因爲資源限制，本例中採用兩臺虛擬機，每臺虛擬機安裝兩個redis實例，共四個來測試

1、安裝redis

https://www.cnblogs.com/qq931399960/p/10616459.html

2、當前安裝的redis分別爲

192.168.102.69:6379 (master)

192.168.102.69:6380 (slave) 

192.168.102.52:6379 (slave)

192.168.102.52:6379 (slave)

3、配置主從複製

5.0版本使用REPLICAOF代替了以前版本的SLAVEOF，若是使用5.0及以後版本，則建議新命令REPLICAOF。

一、命令行方式

分別登陸各slave redis命令行，執行auth xxx賦權，執行以下命令（重啓以後無效）

REPLICAOF 192.168.102.69 6379 CONFIG SET masterauth 12345

若取消複製，則執行以下命令便可

REPLICAOF no one

二、配置方式（永久生效，本例中使用配置方式）

redis slave配置文件中添加以下配置，重啓redis

replicaof 192.168.102.69 6379 masterauth 12345

若取消複製，只須要去掉上述配置，重啓便可

4、驗證

一、登陸從實例，查看info

二、登陸主實例,查看info

重啓以後，replication id和offset會被重置

主實例添加key，從實例查詢，已同步，ok

5、配置只有N個鏈接複製的時候才容許主實例寫操做

我的以爲，若使redis節點高可用，則該項應該使用默認配置，不然可能會出現幾個節點不可用，形成寫操做失敗。

該功能工做原理以下：

一、從實例每秒ping主實例，確認已處理的複製流的數量

二、redis主實例記住最後接收到的從實例ping的時間

三、用戶配置從實例的最小數量在小於指定的最大延遲（秒）時間時可寫。

該功能有兩個配置控制(5.0版本以前replicas改成slaves)

min-replicas-to-write <number of slaves>  （默認0） min-replicas-max-lag <number of seconds>  （默認10）

在redis master配置文件中添加配置

min-replicas-to-write 4 min-replicas-max-lag 10

意爲，當至少4個slave鏈接master的延遲時間小於10秒時，主實例才能夠進行寫操做。

也能夠經過命令行在重啓以前生效

127.0.0.1:6379> CONFIG SET min-replicas-to-write 4 OK 127.0.0.1:6379> CONFIG GET min-replicas-to-write
1) "min-replicas-to-write"
2) "4"
127.0.0.1:6379>

登陸master，執行測試

 

以下爲在redis官網獲取到的一些信息

從實例在與主實例的鏈接斷開後，會自動重連，而且嘗試做爲主實例的一個精確副本。其工做機制以下

一、當主從實例正常鏈接時，主實例發送命令流給從實例來保證數據的一致性

二、因爲網絡問題或者檢測到超時等引發的主從鏈接斷開，從實例將從新鏈接主實例並嘗試進行部分再同步，也就是說，從實例將獲取在鏈接斷開期間丟失的命令流。

三、當部分再同步不可實現，從實例將會請求一個全量再同步。其中包括主實例建立一個全部數據的快照，而且發送給從實例，而後繼續發送數據集改變時的命令流。

默認狀況下，redis使用高性能，低延遲的異步複製。redis從實例異步的獲取接收到的主實例數據量，所以主實例不用每次都等待從實例處理命令，可是主實例嫩鞏固知道從實例的命令的執行狀態

redis基本複製規則

一、redis使用異步複製，異步進行從實例到主實例的數據處理量的確認

二、主實例能夠有多個從實例

三、從實例能夠從其餘從實例處接受數據，從redis4.0起，全部子從實例都從主實例獲取精確的複製流

四、在主實例側，redis複製是非阻塞的。當一個或者多個從實例執行初始化同步或者部分再同步時，主實例將繼續處理查詢請求。

五、在從實例側，複製也基本上是非阻塞的。當從實例正在執行初始化同步時，它可使用老版本的數據集處理查詢。另外，能夠在從實例中配置當複製流中止後，返回一個錯誤給客戶端。可是在數據初始化同步以後，須要刪除舊數據，加載新數據，在這一時期，從實例將會阻塞全部接收到的鏈接（對於一個很是大數據集，可能會持續幾秒）。自從redis4.0，能夠配置在另一個線程中刪除舊數據，可是仍然在主線程中加載新的初始化數據，而且阻塞從實例。

六、redis複製能夠應用於可擴展性，好比有多個從實例提只讀服務，或者僅僅只是用於數據安全和高可用

七、可使用複製來避免主實例將所有數據集寫入到磁盤中。這種使用方式通常在主實例中禁止了持久化，但必須謹慎的設置該功能，由於主實例啓動後，將會清空全部數據，若是從實例向主實例獲取數據，那麼從實例的數據也將爲空

強烈建議在主從實例中都打開持久化。

每一個redis主實例都有一個relication id，它由一個大的僞隨機字符串組成，標記數據集的給定描述。每一個主實例還具備一個偏移量（offset），這個偏移量會一直增長，即便沒有從節點鏈接，複製偏移量也會增長，重啓以前replication id不會變化，重啓以後，replication id和offset都會發生變化。通常replciation id和offset來肯定主實例的一個準確的版本。

當從實例鏈接到主實例，從實例經過PSYNC命令來發送他們的最新的舊主實例replication id和offset，使用這種方式，主服務器能夠只發送所需的增量部分命令流。可是若是主實例緩衝區沒有足夠的backlog，或者從實例指向了一個位置的歷史replication id，那麼將會發生全量再同步。

全量再同步工做原理

主實例啓動一個後臺保存進程生成RDB文件，如此同時，開始緩存全部從客戶端獲取的寫命令，當後臺保存進程結束，主實例將這個RDB數據庫文件傳送給從實例，從實例將其保存在磁盤，而且加載到內存，以後主實例發送全部緩存的命令給從實例。

SYNC是一箇舊的命令，不支持部分再同步，在新版本中已經使用PSYNC代替，考慮到向後兼容，SYNC命令沒有去除

主從鏈接斷開後，從節點能夠自動從新鏈接主實例。若果主實例接收到多個併發的同步請求，其將只執行一個後臺保存進程生成RDB文件，而後將該RDB文件發送給以上併發同步的各請求

 Replication id的解釋

若是兩個實例具備相同的replication id和offset，那麼他們具備相同的數據集。每次主實例重啓或者從實例提高爲主實例，對於這個實例來說，將會產生新的replication id，鏈接到主實例的從實例將在握手以後繼承其replication id。所以具備相同id 的兩個實例是有關聯的，由於他們可能在不一樣的

時間點獲取到了相同的數據。對於一個保存有最新數據的給定歷史節點，偏移量做爲一個邏輯時間來理解。例如：A和B具備相同的replication id，可是其中一個的偏移量爲1000，另一個偏移量爲1023，這意味着第一個實例少執行了一些命令，也能夠說，A實例，執行一些命令以後能夠達到B實例的狀態。

redis具備兩個replication id的緣由在於，提高爲主實例的從實例。在故障轉移中，被提高爲主實例的從實例仍然須要記住它過去的replication id，由於這個replication id是以前主實例的一個id之一，在這種狀況下，其餘將與新主實例進行同步的從實例使用以前舊的主實例的replciation id與新的主實例之間能夠執行部分同步。這和預期一致，由於當從實例提高爲主實例，它將輔id設置爲主id，在id轉換時，記錄偏移量，以後選出一個新的隨機replication id，由於一個新的歷史記錄開始。檔處理新從實例鏈接，主實例將用當前的id和輔id匹配它們的id和offset，簡而言之，故障轉移以後，鏈接到一個新的主實例的從實例不須要執行一個全量同步。

故障轉移以後改變replication id的緣由在於

因爲一些分區，有可能舊的主實例仍然做爲主實例在工做，保留相同的replication id違背了一個相同id和相同offset意味着它們具備相同的數據集的規則。

 只讀從實例

自從2.6版本，從實例默認支持只讀模式，能夠經過配置文件中修改slave-read-only來設置，也能夠經過命令行config set來設置，前者永久生效。但這並不意味着redis從實例就是嚴格的不能寫，由於一些管理命令，好比DEBUG/CONFIG仍然可使用，能夠經過rename-command指令來關閉相關命令以提升安全性。從實例也能夠配置爲可寫，但在4.0版本以前，可寫從實例不能兼容expire命令，也便是，使用expire或者其餘命令設置一個key的ttl最大值，當key到達了指定時間以後，使用讀命令已經不能獲取到key，可是經過dbsize等命令獲取key的數量時，依然包含了該key而且該key依然在佔用內存。redis 4.0 RC3以後版本解決了該問題，而且可寫從實例能夠和主實例同樣能夠經過ttl剔除過時數據。

自從redis4.0，從實例僅本地可寫，但子從實例始終都是從主實例同步數據，如

A -- >B --> C

上述A爲主實例，B爲可寫從實例，C爲只讀從實例，C中的數據內容將與A一致，C不會不一樣在B中寫入，但在A中不存在的數據。

Redis複製處理expires

redis使用三種技術來使expire key生效

一、從實例不過時key，他們等待主實例key過時，當主實例key過時，生成一個DEL命令，發送給從實例。

二、因爲主控驅動過時，有時可能主實例尚未可以提供DEL命令，從實例中還存在邏輯上已經失效的key，此時若是將該key返回給客戶端，這就與邏不符。爲了解決這個問題，從實例在不違法數據集一致性的狀況下，使用它的邏輯時鐘一遍報告一個key並不僅存在於讀取操做中（？），這樣，從實例能夠避免上報邏輯上已通過期的key仍然存在。

三、Lua腳本執行期間，不執行key過時，因此整個腳本執行期間，要麼一個key不存在，要麼一個key一直存在，防止key在腳本執行中間過時。

消息和角色命令

INFO

INFO REPLICATION

ROLE