1 重啟和故障轉(zhuǎn)移后的部分重同步
Redis 4.0 開始，當(dāng)一個實例在故障轉(zhuǎn)移后被提升為 master 時场躯，它仍然能夠與舊 master 的 slave 進行部分重同步笆豁。為此，slave 會記住舊 master 的舊 replication ID 和復(fù)制偏移量攀涵，因此即使詢問舊的 replication ID掷空，也可以將部分復(fù)制緩沖提供給連接的 slave 肋殴。
但是，升級的 slave 的新 replication ID 將不同坦弟，因為它構(gòu)成了數(shù)據(jù)集的不同歷史記錄护锤。例如，master 可以返回可用酿傍，并且可以在一段時間內(nèi)繼續(xù)接受寫入命令烙懦，因此在被提升的 slave 中使用相同的 replication ID 將違反一對復(fù)制標(biāo)識和偏移對只能標(biāo)識單一數(shù)據(jù)集的規(guī)則。
另外赤炒，slave 在關(guān)機并重新啟動后氯析，能夠在 RDB 文件中存儲所需信息，以便與 master 進行重同步莺褒。這在升級的情況下很有用掩缓。當(dāng)需要時，最好使用 SHUTDOWN 命令來執(zhí)行 slave 的保存和退出操作遵岩。
2 主從數(shù)據(jù)不一致
主從網(wǎng)絡(luò)延時：
主多從少
部分重同步你辣。可以通過命令 PSYNC master_run_id offset 執(zhí)行尘执。
主少從多
全量復(fù)制舍哄，覆蓋。這種情況是因為從節(jié)點讀寫模式導(dǎo)致的正卧，關(guān)閉從節(jié)點讀寫模式蠢熄，或者刪除從節(jié)點數(shù)據(jù)跪解，重新從主節(jié)點全量復(fù)制炉旷。
3 數(shù)據(jù)延遲
編寫外部程序監(jiān)聽主從節(jié)點的復(fù)制偏移量签孔，延遲較大時發(fā)出報警或通知客戶端，切換到主節(jié)點或其他節(jié)點窘行。
設(shè)置從節(jié)點slave-serve-stale-data為no,除INFO和SLAVOF命令之外的任何請求都會返回一個錯誤“SYNC with master in progress”饥追。
當(dāng)副本失去與mater的連接時或仍在進行復(fù)制時，副本可以如下方式起作用：
- 若
replica-serve-stale-data設(shè)為“是”（默認值）罐盔，則副本仍會回復(fù)客戶端請求但绕，可能帶有過期數(shù)據(jù)，或者惶看，如果這是第一次同步捏顺，則數(shù)據(jù)集可能只是空的 - 若將
replica-serve-stale-data設(shè)為no，則該副本將對除以下信息以外的所有命令返回錯誤“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 命令刪除鍵對象偏灿，之后異步把 del 命令 slave 節(jié)點丹诀，這樣可以保證數(shù)據(jù)復(fù)制的一致性，slave 永遠不會主動去刪除超時數(shù)據(jù)翁垂。
定時刪除
Redis 的 master 節(jié)點在內(nèi)部定時任務(wù)铆遭，會循環(huán)采樣一定數(shù)量的鍵，當(dāng)發(fā)現(xiàn)采樣的鍵過期時沿猜，會執(zhí)行 del 命令枚荣，之后再同步個 slave 節(jié)點。
主動刪除
當(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é)點（默認讀模式）是讀寫模式慌随，可能誤寫入從節(jié)點的數(shù)據(jù)芬沉，后期就會成為臟數(shù)據(jù)。
4.2 解決方案
忽略
比如 12306 查余票阁猜、雙十一秒殺的庫存丸逸，你會發(fā)現(xiàn)經(jīng)常就是前后不一致的數(shù)據(jù)。因為你查詢時得到的數(shù)據(jù)剃袍，就是需要允許寫錯誤椭员。
選擇性強制讀主
但是真正下單扣庫存時，你就必須確保數(shù)據(jù)的正確性 選擇強制讀 master笛园，slave間接變?yōu)閭浞莘?wù)器（某個業(yè)務(wù)）隘击。
從節(jié)點只讀
防止 slave 寫入臟數(shù)據(jù)。
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)閉主節(jié)點持久化的功能（這樣所有數(shù)據(jù)都會持久化在 slave），因為主從同步時逆甜，master 都會 bgsave rdb虱肄。但這樣也會帶來復(fù)制的安全性問題。
在使用 Redis 復(fù)制功能時的設(shè)置中交煞，推薦在 master 和在 slave 中啟用持久化咏窿。當(dāng)不可能啟用時，例如由于非常慢的磁盤性能而導(dǎo)致的延遲問題素征，應(yīng)該禁用主節(jié)點自動重啟功能集嵌。
為什么關(guān)閉了持久化并配置了自動重啟的 master 是危險的呢：
- 關(guān)閉 Master 的持久化設(shè)置，Replica1 和 Replica2 從 Master 復(fù)制數(shù)據(jù)御毅。此時 Master 只有內(nèi)存數(shù)據(jù)根欧，沒有磁盤數(shù)據(jù)了。
- 當(dāng) master 宕機端蛆，由于自動重啟機制重啟了凤粗，但重啟后由于持久化被關(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ù)集应役。 image
5.1.1 解決方案
- 犧牲性能，開啟 Master 的持久化功能燥筷。
- 為了性能箩祥，依舊選擇關(guān)閉，那就讓主節(jié)點不自動重啟肆氓，比如不要有Docker或腳本等自動重啟機制袍祖。
