文章目錄?? Redis 主從復(fù)制內(nèi)核深潛從物理模型到全量、增量同步的本質(zhì) 文章摘要 核心基礎(chǔ)底層結(jié)構(gòu)與物理模型 核心數(shù)據(jù)結(jié)構(gòu)與狀態(tài)標(biāo)識(shí)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ì)?? 為什么會(huì)失效積壓緩沖區(qū)溢出本質(zhì) 性能優(yōu)化應(yīng)用本質(zhì)與影響?? 主從延遲Replication Lag與一致性代價(jià) 復(fù)制緩沖區(qū)溢出與級(jí)聯(lián)全量風(fēng)暴 拓?fù)浼軜?gòu)演進(jìn)從星型到樹型? 面試回答思路結(jié)構(gòu)化高分話術(shù)? 三步走降維打擊話術(shù)模板?? Redis 主從復(fù)制內(nèi)核深潛從物理模型到全量、增量同步的本質(zhì) 文章摘要Redis 主從復(fù)制是構(gòu)建哨兵集群與分片集群的底層基石。本文從存儲(chǔ)引擎與網(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ì)并給出了針對(duì)主從延遲與拓?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)識(shí)1. RunID實(shí)例運(yùn)行 ID每個(gè) Redis 節(jié)點(diǎn)啟動(dòng)時(shí)都會(huì)生成一個(gè)隨機(jī)的 40 位十六進(jìn)制字符構(gòu)成的 RunID。主從斷開重連時(shí)從節(jié)點(diǎn)會(huì)向主節(jié)點(diǎn)發(fā)送歷史主節(jié)點(diǎn)的 RunID。如果主節(jié)點(diǎn)的 RunID 發(fā)生變化如發(fā)生重啟或主節(jié)點(diǎn)切換說(shuō)明數(shù)據(jù)源已變更無(wú)法進(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ù)后也會(huì)更新自己的 Offset。通過比對(duì)主從 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)只要請(qǐng)求的 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)生的所有新寫命令都會(huì)被寫入此緩沖區(qū)。待 RDB 發(fā)送并加載完畢后該緩沖區(qū)中的指令再追加發(fā)送給從節(jié)點(diǎn)。 核心原理機(jī)制拆解與失效本質(zhì) 全量同步Full Resynchronization全鏈路推演當(dāng)從節(jié)點(diǎn)首次連接主節(jié)點(diǎn)或斷線重連后無(wú)法滿足增量條件時(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ū)積壓命令 ----- | | |握手與請(qǐng)求從節(jié)點(diǎn)發(fā)送PSYNC ? -1表示對(duì)主節(jié)點(diǎn)的 RunID 和 Offset 一無(wú)所知請(qǐng)求全量同步。響應(yīng)全量指令主節(jié)點(diǎn)回復(fù)FULLRESYNC RunID Offset告訴從節(jié)點(diǎn)自己的身份和當(dāng)前的復(fù)制進(jìn)度?？煺丈膳c傳輸主節(jié)點(diǎn)執(zhí)行BGSAVE在后臺(tái)生成 RDB 文件并通過網(wǎng)絡(luò)發(fā)送給從節(jié)點(diǎn)。緩沖區(qū)暫存在 RDB 生成與傳輸過程中主節(jié)點(diǎn)繼續(xù)接收客戶端寫請(qǐng)求。這些命令不會(huì)被丟棄而是實(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ù)制會(huì)嘗試進(jìn)行部分重同步PSYNC從節(jié)點(diǎn)發(fā)送PSYNC RunID Offset。主節(jié)點(diǎn)檢查攜帶的RunID是否與當(dāng)前主節(jié)點(diǎn)一致請(qǐng)求的Offset是否仍在Replication Backlog環(huán)形隊(duì)列的覆蓋范圍內(nèi)如果條件滿足主節(jié)點(diǎn)回復(fù)CONTINUE并僅將環(huán)形隊(duì)列中Offset之后缺失的命令發(fā)送給從節(jié)點(diǎn)。?? 為什么會(huì)失效積壓緩沖區(qū)溢出本質(zhì)如果網(wǎng)絡(luò)斷開時(shí)間過長(zhǎng)或者主節(jié)點(diǎn)寫入吞吐量極高導(dǎo)致環(huán)形隊(duì)列被寫滿并發(fā)生了首尾覆蓋Head Overwrite從節(jié)點(diǎn)請(qǐng)求的Offset已經(jīng)不在積壓緩沖區(qū)內(nèi)主節(jié)點(diǎn)將拒絕部分重同步被迫降級(jí)為全量同步。這也是生產(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)處理完寫請(qǐng)求后立即返回客戶端成功寫命令通過網(wǎng)絡(luò)異步投遞給從節(jié)點(diǎn)。這帶來(lái)了一定的性能代價(jià)讀取陳舊數(shù)據(jù)Stale Read在網(wǎng)絡(luò)抖動(dòng)或從節(jié)點(diǎn)負(fù)載過高時(shí)從節(jié)點(diǎn)數(shù)據(jù)落后于主節(jié)點(diǎn)直接讀取會(huì)產(chǎn)生臟數(shù)據(jù)。解決方案對(duì)強(qiáng)一致性要求的業(yè)務(wù)應(yīng)當(dāng)直連主節(jié)點(diǎn)對(duì)容忍延遲的報(bào)表、統(tǒng)計(jì)類查詢走從節(jié)點(diǎn)實(shí)現(xiàn)讀寫分離。 復(fù)制緩沖區(qū)溢出與級(jí)聯(lián)全量風(fēng)暴Replication Buffer 占用的內(nèi)存如果超過了client-output-buffer-limit replica限制例如硬限制 256MB 或軟限制 64MB 持續(xù) 60 秒主節(jié)點(diǎn)會(huì)主動(dòng)斷開與該從節(jié)點(diǎn)的連接。后果從節(jié)點(diǎn)重連后再次失敗陷入“全量同步 - 緩沖區(qū)溢出斷開 - 再次全量同步”的死循環(huán)全量同步風(fēng)暴。調(diào)優(yōu)策略在高寫入吞吐場(chǎng)景下必須調(diào)大復(fù)制緩沖區(qū)限制并評(píng)估網(wǎng)絡(luò)帶寬避免因單次 RDB 傳輸耗時(shí)過長(zhǎng)撐爆緩沖區(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()會(huì)導(dǎo)致主進(jìn)程阻塞消耗大量 CPU 和磁盤 I/O。樹型拓?fù)銫ascading Replication引入“從節(jié)點(diǎn)的從節(jié)點(diǎn)”級(jí)聯(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è)維度來(lái)剖析定基調(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快速增量追趕否則會(huì)退化為開銷極大的全量同步。談性能與避坑在實(shí)際生產(chǎn)中最核心的痛點(diǎn)是主從延遲與復(fù)制緩沖區(qū)溢出。如果寫入量大且repl-backlog-size設(shè)置過小會(huì)引發(fā)級(jí)聯(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í)踐。”