制內(nèi)核深潛：從物理模型到全量增量同步的本質(zhì))
文章目錄?? Redis 主從復(fù)制內(nèi)核深潛從物理模型到全量、增量同步的本質(zhì) 文章摘要 核心基礎(chǔ)底層結(jié)構(gòu)與物理模型 核心數(shù)據(jù)結(jié)構(gòu)與狀態(tài)標(biāo)識1. RunID實(shí)例運(yùn)行 ID2. Offset復(fù)制偏移量3. Replication Backlog復(fù)制積壓緩沖區(qū)4. Replication Buffer復(fù)制緩沖區(qū) 核心原理機(jī)制拆解與失效本質(zhì) 全量同步Full Resynchronization全鏈路推演 部分重同步Partial Resynchronization與失效本質(zhì)?? 為什么會失效積壓緩沖區(qū)溢出本質(zhì) 性能優(yōu)化應(yīng)用本質(zhì)與影響?? 主從延遲Replication Lag與一致性代價(jià) 復(fù)制緩沖區(qū)溢出與級聯(lián)全量風(fēng)暴 拓?fù)浼軜?gòu)演進(jìn)從星型到樹型? 面試回答思路結(jié)構(gòu)化高分話術(shù)? 三步走降維打擊話術(shù)模板?? Redis 主從復(fù)制內(nèi)核深潛從物理模型到全量、增量同步的本質(zhì) 文章摘要Redis 主從復(fù)制是構(gòu)建哨兵集群與分片集群的底層基石。本文從存儲引擎與網(wǎng)絡(luò)I/O視角出發(fā)深度解構(gòu)了主從復(fù)制的物理模型詳細(xì)剖析了全量同步RDB快照與復(fù)制緩沖區(qū)協(xié)作與部分重同步基于復(fù)制積壓緩沖區(qū)與 Offset/RunID 的環(huán)形復(fù)用機(jī)制的底層運(yùn)作邏輯。同時(shí)指出了復(fù)制積壓區(qū)溢出導(dǎo)致全量同步風(fēng)暴的失效本質(zhì)并給出了針對主從延遲與拓?fù)鋬?yōu)化的生產(chǎn)實(shí)踐方案助力徹底掌握 Redis 數(shù)據(jù)高可用的核心本質(zhì)。 核心基礎(chǔ)底層結(jié)構(gòu)與物理模型Redis 的主從復(fù)制本質(zhì)上是全量數(shù)據(jù)快照與增量命令流式同步的有機(jī)結(jié)合。要理解其運(yùn)作機(jī)制必須先剖析其在內(nèi)存和緩沖區(qū)中的物理布局。 核心數(shù)據(jù)結(jié)構(gòu)與狀態(tài)標(biāo)識1. RunID實(shí)例運(yùn)行 ID每個(gè) Redis 節(jié)點(diǎn)啟動(dòng)時(shí)都會生成一個(gè)隨機(jī)的 40 位十六進(jìn)制字符構(gòu)成的 RunID。主從斷開重連時(shí)從節(jié)點(diǎn)會向主節(jié)點(diǎn)發(fā)送歷史主節(jié)點(diǎn)的 RunID。如果主節(jié)點(diǎn)的 RunID 發(fā)生變化如發(fā)生重啟或主節(jié)點(diǎn)切換說明數(shù)據(jù)源已變更無法進(jìn)行增量同步必須觸發(fā)全量同步。2. Offset復(fù)制偏移量主節(jié)點(diǎn)和從節(jié)點(diǎn)分別維護(hù)各自的復(fù)制偏移量。主節(jié)點(diǎn)每次向從節(jié)點(diǎn)寫入N NN字節(jié)數(shù)據(jù)自身的 Offset 就加上N NN從節(jié)點(diǎn)收到N NN字節(jié)數(shù)據(jù)后也會更新自己的 Offset。通過比對主從 Offset 的差距系統(tǒng)能夠精確計(jì)算出丟失了哪些增量指令。3. Replication Backlog復(fù)制積壓緩沖區(qū)主節(jié)點(diǎn)內(nèi)部維護(hù)的一個(gè)固定大小的先進(jìn)先出FIFO環(huán)形隊(duì)列默認(rèn)大小 1MB由repl-backlog-size配置。它的核心作用是緩存最近執(zhí)行的寫命令。當(dāng)主從斷開重連時(shí)從節(jié)點(diǎn)只要請求的 Offset 仍在積壓緩沖區(qū)的有效范圍內(nèi)就可以直接通過增量同步恢復(fù)而不必重新拉取 RDB。4. Replication Buffer復(fù)制緩沖區(qū)主節(jié)點(diǎn)為每一個(gè)連接的從節(jié)點(diǎn)動(dòng)態(tài)分配的輸出緩沖區(qū)Output Buffer。在執(zhí)行BGSAVE生成 RDB 文件期間主節(jié)點(diǎn)產(chǎn)生的所有新寫命令都會被寫入此緩沖區(qū)。待 RDB 發(fā)送并加載完畢后該緩沖區(qū)中的指令再追加發(fā)送給從節(jié)點(diǎn)。 核心原理機(jī)制拆解與失效本質(zhì) 全量同步Full Resynchronization全鏈路推演當(dāng)從節(jié)點(diǎn)首次連接主節(jié)點(diǎn)或斷線重連后無法滿足增量條件時(shí)將觸發(fā)全量同步----------- ----------- | Slave | | Master | ----------- ----------- | | | ------ 1. PSYNC ? -1 ---------- | | | (觸發(fā) BGSAVE生成 RDB) | ----- 2. FULLRESYNC RunID Off - | | | (傳輸 RDB 文件) | ----- 3. 發(fā)送 RDB 文件數(shù)據(jù) ------ | | | | (清空舊數(shù)據(jù)加載 RDB) | | | (同步期間新寫命令寫入 Replication Buffer) | ----- 4. 發(fā)送緩沖區(qū)積壓命令 ----- | | |握手與請求從節(jié)點(diǎn)發(fā)送PSYNC ? -1表示對主節(jié)點(diǎn)的 RunID 和 Offset 一無所知請求全量同步。響應(yīng)全量指令主節(jié)點(diǎn)回復(fù)FULLRESYNC RunID Offset告訴從節(jié)點(diǎn)自己的身份和當(dāng)前的復(fù)制進(jìn)度?？煺丈膳c傳輸主節(jié)點(diǎn)執(zhí)行BGSAVE在后臺生成 RDB 文件并通過網(wǎng)絡(luò)發(fā)送給從節(jié)點(diǎn)。緩沖區(qū)暫存在 RDB 生成與傳輸過程中主節(jié)點(diǎn)繼續(xù)接收客戶端寫請求。這些命令不會被丟棄而是實(shí)時(shí)寫入Replication Buffer。數(shù)據(jù)載入與追趕從節(jié)點(diǎn)清空本地舊數(shù)據(jù)加載接收到的 RDB 文件加載完成后主節(jié)點(diǎn)將 Replication Buffer 中的指令流發(fā)送給從節(jié)點(diǎn)執(zhí)行達(dá)成狀態(tài)一致。 部分重同步Partial Resynchronization與失效本質(zhì)當(dāng)網(wǎng)絡(luò)發(fā)生瞬時(shí)閃斷從節(jié)點(diǎn)重新連接時(shí)主從復(fù)制會嘗試進(jìn)行部分重同步PSYNC從節(jié)點(diǎn)發(fā)送PSYNC RunID Offset。主節(jié)點(diǎn)檢查攜帶的RunID是否與當(dāng)前主節(jié)點(diǎn)一致請求的Offset是否仍在Replication Backlog環(huán)形隊(duì)列的覆蓋范圍內(nèi)如果條件滿足主節(jié)點(diǎn)回復(fù)CONTINUE并僅將環(huán)形隊(duì)列中Offset之后缺失的命令發(fā)送給從節(jié)點(diǎn)。?? 為什么會失效積壓緩沖區(qū)溢出本質(zhì)如果網(wǎng)絡(luò)斷開時(shí)間過長或者主節(jié)點(diǎn)寫入吞吐量極高導(dǎo)致環(huán)形隊(duì)列被寫滿并發(fā)生了首尾覆蓋Head Overwrite從節(jié)點(diǎn)請求的Offset已經(jīng)不在積壓緩沖區(qū)內(nèi)主節(jié)點(diǎn)將拒絕部分重同步被迫降級為全量同步。這也是生產(chǎn)環(huán)境中必須合理調(diào)大repl-backlog-size如設(shè)為幾十甚至上百 MB的核心原因。 性能優(yōu)化應(yīng)用本質(zhì)與影響?? 主從延遲Replication Lag與一致性代價(jià)主從復(fù)制是異步進(jìn)行的。主節(jié)點(diǎn)處理完寫請求后立即返回客戶端成功寫命令通過網(wǎng)絡(luò)異步投遞給從節(jié)點(diǎn)。這帶來了一定的性能代價(jià)讀取陳舊數(shù)據(jù)Stale Read在網(wǎng)絡(luò)抖動(dòng)或從節(jié)點(diǎn)負(fù)載過高時(shí)從節(jié)點(diǎn)數(shù)據(jù)落后于主節(jié)點(diǎn)直接讀取會產(chǎn)生臟數(shù)據(jù)。解決方案對強(qiáng)一致性要求的業(yè)務(wù)應(yīng)當(dāng)直連主節(jié)點(diǎn)對容忍延遲的報(bào)表、統(tǒng)計(jì)類查詢走從節(jié)點(diǎn)實(shí)現(xiàn)讀寫分離。 復(fù)制緩沖區(qū)溢出與級聯(lián)全量風(fēng)暴Replication Buffer 占用的內(nèi)存如果超過了client-output-buffer-limit replica限制例如硬限制 256MB 或軟限制 64MB 持續(xù) 60 秒主節(jié)點(diǎn)會主動(dòng)斷開與該從節(jié)點(diǎn)的連接。后果從節(jié)點(diǎn)重連后再次失敗陷入“全量同步 - 緩沖區(qū)溢出斷開 - 再次全量同步”的死循環(huán)全量同步風(fēng)暴。調(diào)優(yōu)策略在高寫入吞吐場景下必須調(diào)大復(fù)制緩沖區(qū)限制并評估網(wǎng)絡(luò)帶寬避免因單次 RDB 傳輸耗時(shí)過長撐爆緩沖區(qū)。 拓?fù)浼軜?gòu)演進(jìn)從星型到樹型如果主節(jié)點(diǎn)直連大量的從節(jié)點(diǎn)星型拓?fù)涿慨?dāng)有新的從節(jié)點(diǎn)發(fā)起全量同步時(shí)主節(jié)點(diǎn)都要頻繁執(zhí)行BGSAVE。頻繁的fork()會導(dǎo)致主進(jìn)程阻塞消耗大量 CPU 和磁盤 I/O。樹型拓?fù)銫ascading Replication引入“從節(jié)點(diǎn)的從節(jié)點(diǎn)”級聯(lián)架構(gòu)讓部分從節(jié)點(diǎn)作為中間代理節(jié)點(diǎn)分擔(dān)主節(jié)點(diǎn)的復(fù)制壓力實(shí)現(xiàn)分層同步。? 面試回答思路結(jié)構(gòu)化高分話術(shù)? 三步走降維打擊話術(shù)模板“面試官您好關(guān)于 Redis 主從復(fù)制的底層原理我習(xí)慣從架構(gòu)定位、核心機(jī)制與線上調(diào)優(yōu)三個(gè)維度來剖析定基調(diào)主從復(fù)制是 Redis 實(shí)現(xiàn)高可用哨兵機(jī)制、Cluster 分片集群和讀寫分離的基石。它通過保證多個(gè)節(jié)點(diǎn)間的數(shù)據(jù)最終一致性解決了單機(jī) Redis 的單點(diǎn)故障與并發(fā)瓶頸問題。講本質(zhì)其核心分為全量同步和部分重同步。全量同步通過BGSAVE生成 RDB 配合Replication Buffer完成冷數(shù)據(jù)初始化。增量同步則依賴Replication Backlog一個(gè)環(huán)形隊(duì)列以及RunID和Offset。只要斷連時(shí)間短、Offset 未被環(huán)形隊(duì)列覆蓋就能通過PSYNC快速增量追趕否則會退化為開銷極大的全量同步。談性能與避坑在實(shí)際生產(chǎn)中最核心的痛點(diǎn)是主從延遲與復(fù)制緩沖區(qū)溢出。如果寫入量大且repl-backlog-size設(shè)置過小會引發(fā)級聯(lián)的全量同步風(fēng)暴導(dǎo)致主節(jié)點(diǎn) CPU 飆升。因此合理規(guī)劃 Backlog 大小、監(jiān)控 Offset 延遲、在超大集群中采用樹型復(fù)制拓?fù)涫潜Ｕ?Redis 穩(wěn)定運(yùn)行的關(guān)鍵工程實(shí)踐?！? Redis 主從復(fù)制內(nèi)核深潛：從物理模型到全量增量同步的本質(zhì)
文章目錄?? Redis 主從復(fù)制內(nèi)核深潛從物理模型到全量、增量同步的本質(zhì) 文章摘要 核心基礎(chǔ)底層結(jié)構(gòu)與物理模型 核心數(shù)據(jù)結(jié)構(gòu)與狀態(tài)標(biāo)識1. RunID實(shí)例運(yùn)行 ID2. Offset復(fù)制偏移量3. Replication Backlog復(fù)制積壓緩沖區(qū)4. Replication Buffer復(fù)制緩沖區(qū) 核心原理機(jī)制拆解與失效本質(zhì) 全量同步Full Resynchronization全鏈路推演 部分重同步Partial Resynchronization與失效本質(zhì)?? 為什么會失效積壓緩沖區(qū)溢出本質(zhì) 性能優(yōu)化應(yīng)用本質(zhì)與影響?? 主從延遲Replication Lag與一致性代價(jià) 復(fù)制緩沖區(qū)溢出與級聯(lián)全量風(fēng)暴 拓?fù)浼軜?gòu)演進(jìn)從星型到樹型? 面試回答思路結(jié)構(gòu)化高分話術(shù)? 三步走降維打擊話術(shù)模板?? Redis 主從復(fù)制內(nèi)核深潛從物理模型到全量、增量同步的本質(zhì) 文章摘要Redis 主從復(fù)制是構(gòu)建哨兵集群與分片集群的底層基石。本文從存儲引擎與網(wǎng)絡(luò)I/O視角出發(fā)深度解構(gòu)了主從復(fù)制的物理模型詳細(xì)剖析了全量同步RDB快照與復(fù)制緩沖區(qū)協(xié)作與部分重同步基于復(fù)制積壓緩沖區(qū)與 Offset/RunID 的環(huán)形復(fù)用機(jī)制的底層運(yùn)作邏輯。同時(shí)指出了復(fù)制積壓區(qū)溢出導(dǎo)致全量同步風(fēng)暴的失效本質(zhì)并給出了針對主從延遲與拓?fù)鋬?yōu)化的生產(chǎn)實(shí)踐方案助力徹底掌握 Redis 數(shù)據(jù)高可用的核心本質(zhì)。 核心基礎(chǔ)底層結(jié)構(gòu)與物理模型Redis 的主從復(fù)制本質(zhì)上是全量數(shù)據(jù)快照與增量命令流式同步的有機(jī)結(jié)合。要理解其運(yùn)作機(jī)制必須先剖析其在內(nèi)存和緩沖區(qū)中的物理布局。 核心數(shù)據(jù)結(jié)構(gòu)與狀態(tài)標(biāo)識1. RunID實(shí)例運(yùn)行 ID每個(gè) Redis 節(jié)點(diǎn)啟動(dòng)時(shí)都會生成一個(gè)隨機(jī)的 40 位十六進(jìn)制字符構(gòu)成的 RunID。主從斷開重連時(shí)從節(jié)點(diǎn)會向主節(jié)點(diǎn)發(fā)送歷史主節(jié)點(diǎn)的 RunID。如果主節(jié)點(diǎn)的 RunID 發(fā)生變化如發(fā)生重啟或主節(jié)點(diǎn)切換說明數(shù)據(jù)源已變更無法進(jìn)行增量同步必須觸發(fā)全量同步。2. Offset復(fù)制偏移量主節(jié)點(diǎn)和從節(jié)點(diǎn)分別維護(hù)各自的復(fù)制偏移量。主節(jié)點(diǎn)每次向從節(jié)點(diǎn)寫入N NN字節(jié)數(shù)據(jù)自身的 Offset 就加上N NN從節(jié)點(diǎn)收到N NN字節(jié)數(shù)據(jù)后也會更新自己的 Offset。通過比對主從 Offset 的差距系統(tǒng)能夠精確計(jì)算出丟失了哪些增量指令。3. Replication Backlog復(fù)制積壓緩沖區(qū)主節(jié)點(diǎn)內(nèi)部維護(hù)的一個(gè)固定大小的先進(jìn)先出FIFO環(huán)形隊(duì)列默認(rèn)大小 1MB由repl-backlog-size配置。它的核心作用是緩存最近執(zhí)行的寫命令。當(dāng)主從斷開重連時(shí)從節(jié)點(diǎn)只要請求的 Offset 仍在積壓緩沖區(qū)的有效范圍內(nèi)就可以直接通過增量同步恢復(fù)而不必重新拉取 RDB。4. Replication Buffer復(fù)制緩沖區(qū)主節(jié)點(diǎn)為每一個(gè)連接的從節(jié)點(diǎn)動(dòng)態(tài)分配的輸出緩沖區(qū)Output Buffer。在執(zhí)行BGSAVE生成 RDB 文件期間主節(jié)點(diǎn)產(chǎn)生的所有新寫命令都會被寫入此緩沖區(qū)。待 RDB 發(fā)送并加載完畢后該緩沖區(qū)中的指令再追加發(fā)送給從節(jié)點(diǎn)。 核心原理機(jī)制拆解與失效本質(zhì) 全量同步Full Resynchronization全鏈路推演當(dāng)從節(jié)點(diǎn)首次連接主節(jié)點(diǎn)或斷線重連后無法滿足增量條件時(shí)將觸發(fā)全量同步----------- ----------- | Slave | | Master | ----------- ----------- | | | ------ 1. PSYNC ? -1 ---------- | | | (觸發(fā) BGSAVE生成 RDB) | ----- 2. FULLRESYNC RunID Off - | | | (傳輸 RDB 文件) | ----- 3. 發(fā)送 RDB 文件數(shù)據(jù) ------ | | | | (清空舊數(shù)據(jù)加載 RDB) | | | (同步期間新寫命令寫入 Replication Buffer) | ----- 4. 發(fā)送緩沖區(qū)積壓命令 ----- | | |握手與請求從節(jié)點(diǎn)發(fā)送PSYNC ? -1表示對主節(jié)點(diǎn)的 RunID 和 Offset 一無所知請求全量同步。響應(yīng)全量指令主節(jié)點(diǎn)回復(fù)FULLRESYNC RunID Offset告訴從節(jié)點(diǎn)自己的身份和當(dāng)前的復(fù)制進(jìn)度?？煺丈膳c傳輸主節(jié)點(diǎn)執(zhí)行BGSAVE在后臺生成 RDB 文件并通過網(wǎng)絡(luò)發(fā)送給從節(jié)點(diǎn)。緩沖區(qū)暫存在 RDB 生成與傳輸過程中主節(jié)點(diǎn)繼續(xù)接收客戶端寫請求。這些命令不會被丟棄而是實(shí)時(shí)寫入Replication Buffer。數(shù)據(jù)載入與追趕從節(jié)點(diǎn)清空本地舊數(shù)據(jù)加載接收到的 RDB 文件加載完成后主節(jié)點(diǎn)將 Replication Buffer 中的指令流發(fā)送給從節(jié)點(diǎn)執(zhí)行達(dá)成狀態(tài)一致。 部分重同步Partial Resynchronization與失效本質(zhì)當(dāng)網(wǎng)絡(luò)發(fā)生瞬時(shí)閃斷從節(jié)點(diǎn)重新連接時(shí)主從復(fù)制會嘗試進(jìn)行部分重同步PSYNC從節(jié)點(diǎn)發(fā)送PSYNC RunID Offset。主節(jié)點(diǎn)檢查攜帶的RunID是否與當(dāng)前主節(jié)點(diǎn)一致請求的Offset是否仍在Replication Backlog環(huán)形隊(duì)列的覆蓋范圍內(nèi)如果條件滿足主節(jié)點(diǎn)回復(fù)CONTINUE并僅將環(huán)形隊(duì)列中Offset之后缺失的命令發(fā)送給從節(jié)點(diǎn)。?? 為什么會失效積壓緩沖區(qū)溢出本質(zhì)如果網(wǎng)絡(luò)斷開時(shí)間過長或者主節(jié)點(diǎn)寫入吞吐量極高導(dǎo)致環(huán)形隊(duì)列被寫滿并發(fā)生了首尾覆蓋Head Overwrite從節(jié)點(diǎn)請求的Offset已經(jīng)不在積壓緩沖區(qū)內(nèi)主節(jié)點(diǎn)將拒絕部分重同步被迫降級為全量同步。這也是生產(chǎn)環(huán)境中必須合理調(diào)大repl-backlog-size如設(shè)為幾十甚至上百 MB的核心原因。 性能優(yōu)化應(yīng)用本質(zhì)與影響?? 主從延遲Replication Lag與一致性代價(jià)主從復(fù)制是異步進(jìn)行的。主節(jié)點(diǎn)處理完寫請求后立即返回客戶端成功寫命令通過網(wǎng)絡(luò)異步投遞給從節(jié)點(diǎn)。這帶來了一定的性能代價(jià)讀取陳舊數(shù)據(jù)Stale Read在網(wǎng)絡(luò)抖動(dòng)或從節(jié)點(diǎn)負(fù)載過高時(shí)從節(jié)點(diǎn)數(shù)據(jù)落后于主節(jié)點(diǎn)直接讀取會產(chǎn)生臟數(shù)據(jù)。解決方案對強(qiáng)一致性要求的業(yè)務(wù)應(yīng)當(dāng)直連主節(jié)點(diǎn)對容忍延遲的報(bào)表、統(tǒng)計(jì)類查詢走從節(jié)點(diǎn)實(shí)現(xiàn)讀寫分離。 復(fù)制緩沖區(qū)溢出與級聯(lián)全量風(fēng)暴Replication Buffer 占用的內(nèi)存如果超過了client-output-buffer-limit replica限制例如硬限制 256MB 或軟限制 64MB 持續(xù) 60 秒主節(jié)點(diǎn)會主動(dòng)斷開與該從節(jié)點(diǎn)的連接。后果從節(jié)點(diǎn)重連后再次失敗陷入“全量同步 - 緩沖區(qū)溢出斷開 - 再次全量同步”的死循環(huán)全量同步風(fēng)暴。調(diào)優(yōu)策略在高寫入吞吐場景下必須調(diào)大復(fù)制緩沖區(qū)限制并評估網(wǎng)絡(luò)帶寬避免因單次 RDB 傳輸耗時(shí)過長撐爆緩沖區(qū)。 拓?fù)浼軜?gòu)演進(jìn)從星型到樹型如果主節(jié)點(diǎn)直連大量的從節(jié)點(diǎn)星型拓?fù)涿慨?dāng)有新的從節(jié)點(diǎn)發(fā)起全量同步時(shí)主節(jié)點(diǎn)都要頻繁執(zhí)行BGSAVE。頻繁的fork()會導(dǎo)致主進(jìn)程阻塞消耗大量 CPU 和磁盤 I/O。樹型拓?fù)銫ascading Replication引入“從節(jié)點(diǎn)的從節(jié)點(diǎn)”級聯(lián)架構(gòu)讓部分從節(jié)點(diǎn)作為中間代理節(jié)點(diǎn)分擔(dān)主節(jié)點(diǎn)的復(fù)制壓力實(shí)現(xiàn)分層同步。? 面試回答思路結(jié)構(gòu)化高分話術(shù)? 三步走降維打擊話術(shù)模板“面試官您好關(guān)于 Redis 主從復(fù)制的底層原理我習(xí)慣從架構(gòu)定位、核心機(jī)制與線上調(diào)優(yōu)三個(gè)維度來剖析定基調(diào)主從復(fù)制是 Redis 實(shí)現(xiàn)高可用哨兵機(jī)制、Cluster 分片集群和讀寫分離的基石。它通過保證多個(gè)節(jié)點(diǎn)間的數(shù)據(jù)最終一致性解決了單機(jī) Redis 的單點(diǎn)故障與并發(fā)瓶頸問題。講本質(zhì)其核心分為全量同步和部分重同步。全量同步通過BGSAVE生成 RDB 配合Replication Buffer完成冷數(shù)據(jù)初始化。增量同步則依賴Replication Backlog一個(gè)環(huán)形隊(duì)列以及RunID和Offset。只要斷連時(shí)間短、Offset 未被環(huán)形隊(duì)列覆蓋就能通過PSYNC快速增量追趕否則會退化為開銷極大的全量同步。談性能與避坑在實(shí)際生產(chǎn)中最核心的痛點(diǎn)是主從延遲與復(fù)制緩沖區(qū)溢出。如果寫入量大且repl-backlog-size設(shè)置過小會引發(fā)級聯(lián)的全量同步風(fēng)暴導(dǎo)致主節(jié)點(diǎn) CPU 飆升。因此合理規(guī)劃 Backlog 大小、監(jiān)控 Offset 延遲、在超大集群中采用樹型復(fù)制拓?fù)涫潜Ｕ?Redis 穩(wěn)定運(yùn)行的關(guān)鍵工程實(shí)踐?！?