[[392661]]

1 重啟和故障轉(zhuǎn)移后的部分重同步

Redis 4.0 開始，當(dāng)一個實例在故障轉(zhuǎn)移后被提升為 master，它仍能與舊 master 的 Replica 進(jìn)行部分重同步。為此，Replica 會記住舊 master 的舊 replication ID 和復(fù)制偏移量，因此即使詢問舊的 replication ID，也可以將部分復(fù)制緩沖提供給連接的 Replica 。

但升級的 Replica 的新 replication ID 將不同，因為它構(gòu)成了數(shù)據(jù)集的不同歷史記錄。例如，master 可以返回可用，并且可以在一段時間內(nèi)繼續(xù)接收寫命令，因此在被提升的 Replica 中使用相同的 replication ID 將違反 一對復(fù)制標(biāo)識和偏移對只能標(biāo)識單一數(shù)據(jù)集 規(guī)則。

Replica 在關(guān)機(jī)并重啟后，能夠在 RDB 文件中存儲所需信息，以便與 master 進(jìn)行重同步。這在升級的情況下很有用。當(dāng)需要時，最好使用 SHUTDOWN 命令執(zhí)行 Replica 的保存和退出操作。

2 主從數(shù)據(jù)不一致

很顯然，這是由于主從網(wǎng)絡(luò)延時。

2.1 主多從少

部分重同步?？赏ㄟ^命令 PSYNC master_run_id offset 執(zhí)行。

2.2 主少從多

全量復(fù)制，覆蓋。這種情況是因為 Replica 是讀寫模式，因此：

關(guān)閉 Replica 的讀寫模式

或刪除 Replica 的數(shù)據(jù)，重新從 Master 全量復(fù)制

3 數(shù)據(jù)延遲

編寫外部程序監(jiān)聽主從節(jié)點的復(fù)制偏移量，延遲較大時發(fā)出報警或通知客戶端，切換到 Master 或其他節(jié)點。

設(shè)置 Replica：

slave-serve-stale-data = no 

除 INFO 和 SLAVOF 命令之外的任何請求都會返回一個錯誤“SYNC with master in progress”。

當(dāng) Replica 失去與Master 的連接時或仍在進(jìn)行復(fù)制時，Replica 可以如下方式起作用：

• 若 replica-serve-stale-data 為 yes(默認(rèn)值)，則 Replica 仍會回復(fù)客戶端請求，可能帶有過期數(shù)據(jù)，或者說，若這是第一次同步，則數(shù)據(jù)集可能只是空的

• 若將 replica-serve-stale-data 設(shè)為no，則該 Replica 將對除以下信息以外的所有命令返回錯誤“SYNC with master in progress”：INFO，REPLICAOF，AUTH，PING，SHUTDOWN，REPLCONF，ROLE，CONFIG ，SUBSCRIBE，UNSUBSCRIBE，PSUBSCRIBE，PUNSUBSCRIBE，PUBLISH，PUBSUB，COMMAND，POST，HOST和LATENCY

4 臟數(shù)據(jù)

4.1 臟數(shù)據(jù)產(chǎn)因

4.1.1 Redis 刪除策略

因為讀到了過期數(shù)據(jù)，而讀到過期數(shù)據(jù)就是 Redis 刪除策略所導(dǎo)致的：

惰性刪除

Master 每次讀取命令時都會檢查K是否超時，若超時，則執(zhí)行 del 命令刪除K，之后異步把 del 命令同步給 Replica，即可保證數(shù)據(jù)復(fù)制的一致性。切記 Replica 永遠(yuǎn)不會主動去刪除超時數(shù)據(jù)。

定時刪除

Redis 的 Master 在內(nèi)部有定時任務(wù)，會循環(huán)采樣一定數(shù)量的K，當(dāng)發(fā)現(xiàn)采樣K過期，會執(zhí)行 del，之后再同步給每個 Replica。

主動刪除

當(dāng)前已用內(nèi)存超過 maxmemory 限定時，觸發(fā)主動清理策略。主動設(shè)置的前提是設(shè)置了 maxMemory 的值 注：如果數(shù)據(jù)大量超時，master 節(jié)點采樣速度跟不上過期的速度，而且 master 節(jié)點沒有讀取過期鍵的操作，那 slave 節(jié)點是無法收到 del 命令的，這時從節(jié)點上讀取的數(shù)據(jù)已經(jīng)是超時的了。

4.1.2 從節(jié)點可寫

如果從節(jié)點(默認(rèn)讀模式)是讀寫模式，可能誤寫入從節(jié)點的數(shù)據(jù)，后期就會成為臟數(shù)據(jù)。

4.2 解決方案

4.2.1 忽略

比如 12306 查余票、雙十一秒殺的庫存，你會發(fā)現(xiàn)經(jīng)常就是前后不一致的數(shù)據(jù)。因為你查詢時得到的數(shù)據(jù)，就是需要允許寫錯誤。

4.2.2 選擇性強(qiáng)制讀主

但是真正下單扣庫存時，你就必須確保數(shù)據(jù)的正確性 選擇強(qiáng)制讀 master，slave間接變?yōu)閭浞莘?wù)器(某個業(yè)務(wù))。

4.2.3 從節(jié)點只讀

防止 slave 寫入臟數(shù)據(jù)。

4.2.4 Redis自身優(yōu)化

Redis3.2 版本解決了 Redis 刪除策略導(dǎo)致的過期數(shù)據(jù)，在此版本中 slave 讀數(shù)據(jù)前，會檢查K過期時間，以決定是否返回數(shù)據(jù)。

5 數(shù)據(jù)安全性

5.1 關(guān)閉主節(jié)點持久化

為提升Redis性能，一般會關(guān)閉 Master 持久化的功能(這樣所有數(shù)據(jù)都會持久化在 slave)，因為主從同步時，Master 都會 bgsave rdb。但這樣也會帶來復(fù)制的安全性問題。

在使用 Redis 復(fù)制功能時的設(shè)置中，推薦在 master 和在 slave 中啟用持久化。當(dāng)不可能啟用時，例如由于非常慢的磁盤性能而導(dǎo)致的延遲問題，應(yīng)該禁用主節(jié)點自動重啟功能。

風(fēng)險場景

關(guān)閉 Master 的持久化設(shè)置，Replica1 和 Replica2 從 Master 復(fù)制數(shù)據(jù)。Master 只有內(nèi)存數(shù)據(jù)，沒有磁盤數(shù)據(jù)了。

當(dāng) Master 宕機(jī)，由于自動重啟機(jī)制重啟了，但重啟后由于持久化被關(guān)閉了，Master數(shù)據(jù)集為空!

重啟后的 Master，發(fā)現(xiàn) runId 發(fā)生變化，也會重新和從節(jié)點建立連接，兩個從節(jié)點會發(fā)起復(fù)制請求，從Master 復(fù)制數(shù)據(jù)，但 Master 此時數(shù)據(jù)集為空，因此復(fù)制的結(jié)果是它們會銷毀自身之前的數(shù)據(jù)副本而變成空數(shù)據(jù)集。 圖片

5.1.1 解決方案

犧牲性能，開啟 Master 的持久化功能。

為了性能，依舊選擇關(guān)閉，那就讓主節(jié)點不自動重啟，比如不要有Docker或腳本等自動重啟機(jī)制。

本文轉(zhuǎn)載自微信公眾號「JavaEdge」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系JavaEdge公眾號。