本文節(jié)選自《300分鐘吃透分布式緩存》27講
作者：陳波
我們知道，當(dāng)有多臺 redis 服務(wù)器時(shí)，肯定就有一臺主服務(wù)器和多臺從服務(wù)器。一般來說，主服務(wù)器進(jìn)行寫操作，從服務(wù)器進(jìn)行讀操作。
那么，從服務(wù)器如何和主服務(wù)器進(jìn)行數(shù)據(jù)同步的呢？
其實(shí)就是通過主從復(fù)制來實(shí)現(xiàn)的。
本篇內(nèi)容主要分享 Redis 復(fù)制原理，以及復(fù)制分析等內(nèi)容。
Redis 復(fù)制原理
為了避免單點(diǎn)故障，數(shù)據(jù)存儲需要進(jìn)行多副本構(gòu)建。同時(shí)由于 Redis 的核心操作是單線程模型的，單個(gè) Redis 實(shí)例能處理的請求 TPS 有限。因此 Redis 自面世起，基本就提供了復(fù)制功能，而且對復(fù)制策略不斷進(jìn)行優(yōu)化。
通過數(shù)據(jù)復(fù)制，Redis 的一個(gè) master 可以掛載多個(gè) slave，而 slave 下還可以掛載多個(gè) slave，形成多層嵌套結(jié)構(gòu)。所有寫操作都在 master 實(shí)例中進(jìn)行，master 執(zhí)行完畢后，將寫指令分發(fā)給掛在自己下面的 slave 節(jié)點(diǎn)。slave 節(jié)點(diǎn)下如果有嵌套的 slave，會將收到的寫指令進(jìn)一步分發(fā)給掛在自己下面的 slave。
通過多個(gè) slave，Redis 的節(jié)點(diǎn)數(shù)據(jù)就可以實(shí)現(xiàn)多副本保存，任何一個(gè)節(jié)點(diǎn)異常都不會導(dǎo)致數(shù)據(jù)丟失，同時(shí)多 slave 可以 N 倍提升讀性能。master 只寫不讀，這樣整個(gè) master-slave 組合，讀寫能力都可以得到大幅提升。
master 在分發(fā)寫請求時(shí)，同時(shí)會將寫指令復(fù)制一份存入復(fù)制積壓緩沖，這樣當(dāng) slave 短時(shí)間斷開重連時(shí)，只要 slave 的復(fù)制位置點(diǎn)仍然在復(fù)制積壓緩沖，則可以從之前的復(fù)制位置點(diǎn)之后繼續(xù)進(jìn)行復(fù)制，提升復(fù)制效率。
主庫 master 和從庫 slave 之間通過復(fù)制 id 進(jìn)行匹配，避免 slave 掛到錯(cuò)誤的 master。Redis 的復(fù)制分為全量同步和增量同步。
Redis 在進(jìn)行全量同步時(shí)，master 會將內(nèi)存數(shù)據(jù)通過 bgsave 落地到 rdb，同時(shí)，將構(gòu)建 內(nèi)存快照期間 的寫指令，存放到復(fù)制緩沖中，當(dāng) rdb 快照構(gòu)建完畢后，master 將 rdb 和復(fù)制緩沖隊(duì)列中的數(shù)據(jù)全部發(fā)送給 slave，slave 完全重新創(chuàng)建一份數(shù)據(jù)。
這個(gè)過程，對 master 的性能損耗較大，slave 構(gòu)建數(shù)據(jù)的時(shí)間也比較長，而且傳遞 rdb 時(shí)還會占用大量帶寬，對整個(gè)系統(tǒng)的性能和資源的訪問影響都比較大。
而增量復(fù)制，master 只發(fā)送 slave 上次復(fù)制位置之后的寫指令，不用構(gòu)建 rdb，而且傳輸內(nèi)容非常有限，對 master、slave 的負(fù)荷影響很小，對帶寬的影響可以忽略，整個(gè)系統(tǒng)受影響非常小。
在 Redis 2.8 之前，Redis 基本只支持全量復(fù)制。在 slave 與 master 斷開連接，或 slave 重啟后，都需要進(jìn)行全量復(fù)制。在 2.8 版本之后，Redis 引入 psync，增加了一個(gè)復(fù)制積壓緩沖，在將寫指令同步給 slave 時(shí)，會同時(shí)在復(fù)制積壓緩沖中也寫一份。
在 slave 短時(shí)斷開重連后，上報(bào)master runid 及復(fù)制偏移量。如果 runid 與 master 一致，且偏移量仍然在 master 的復(fù)制緩沖積壓中，則 master 進(jìn)行增量同步。
但如果 slave 重啟后，master runid 會丟失，或者切換 master 后，runid 會變化，仍然需要全量同步。
因此 Redis 自 4.0 強(qiáng)化了 psync，引入了 psync2。在 pysnc2 中，主從復(fù)制不再使用 runid，而使用 replid（即復(fù)制id） 來作為復(fù)制判斷依據(jù)。同時(shí) Redis 實(shí)例在構(gòu)建 rdb 時(shí)，會將 replid 作為 aux 輔助信息存入 rbd。重啟時(shí)，加載 rdb 時(shí)即可得到 master 的復(fù)制 id。從而在 slave 重啟后仍然可以增量同步。
在 psync2 中，Redis 每個(gè)實(shí)例除了會有一個(gè)復(fù)制 id 即 replid 外，還有一個(gè) replid2。Redis 啟動后，會創(chuàng)建一個(gè)長度為 40 的隨機(jī)字符串，作為 replid 的初值，在建立主從連接后，會用 master的 replid 替換自己的 replid。同時(shí)會用 replid2 存儲上次 master 主庫的 replid。這樣切主時(shí)，即便 slave 匯報(bào)的復(fù)制 id 與新 master 的 replid 不同，但和新 master 的 replid2 相同，同時(shí)復(fù)制偏移仍然在復(fù)制積壓緩沖區(qū)內(nèi)，仍然可以實(shí)現(xiàn)增量復(fù)制。
Redis 復(fù)制分析
在設(shè)置 master、slave 時(shí)，首先通過配置或者命令 slaveof no one 將節(jié)點(diǎn)設(shè)置為主庫。然后其他各個(gè)從庫節(jié)點(diǎn)，通過 slaveof $master_ip $master_port，將其他從庫掛在到 master 上。
同樣方法，還可以將 slave 節(jié)點(diǎn)掛載到已有的 slave 節(jié)點(diǎn)上。在準(zhǔn)備開始數(shù)據(jù)復(fù)制時(shí)，slave 首先會主動與 master 創(chuàng)建連接，并上報(bào)信息。具體流程如下。
slave 創(chuàng)建與 master 的連接后，首先發(fā)送 ping 指令，如果 master 沒有返回異常，而是返回 pong，則說明 master 可用。
如果 Redis 設(shè)置了密碼，slave 會發(fā)送 auth $masterauth 指令，進(jìn)行鑒權(quán)。當(dāng)鑒權(quán)完畢，從庫就通過 replconf 發(fā)送自己的端口及 IP 給 master。
接下來，slave 繼續(xù)通過 replconf 發(fā)送 capa eof capa psync2 進(jìn)行復(fù)制版本校驗(yàn)。如果 master 校驗(yàn)成功。從庫接下來就通過 psync 將自己的復(fù)制 id、復(fù)制偏移發(fā)送給 master，正式開始準(zhǔn)備數(shù)據(jù)同步。
主庫接收到從庫發(fā)來的 psync 指令后，則開始判斷可以進(jìn)行數(shù)據(jù)同步的方式。
前面講到，Redis 當(dāng)前保存了復(fù)制 id，replid 和 replid2。如果從庫發(fā)來的復(fù)制 id，與 master 的復(fù)制 id（即 replid 和 replid2）相同，并且復(fù)制偏移在復(fù)制緩沖積壓中，則可以進(jìn)行增量同步。master 發(fā)送 continue 響應(yīng)，并返回 master 的 replid。slave 將 master 的 replid 替換為自己的 replid，并將之前的復(fù)制 id 設(shè)置為 replid2。之后，master 則可繼續(xù)發(fā)送，復(fù)制偏移位置 之后的指令，給 slave，完成數(shù)據(jù)同步。
如果主庫發(fā)現(xiàn)從庫傳來的復(fù)制 id 和自己的 replid、replid2 都不同，或者復(fù)制偏移不在復(fù)制積壓緩沖中，則判定需要進(jìn)行全量復(fù)制。master 發(fā)送 fullresync 響應(yīng)，附帶 replid 及復(fù)制偏移。然后， master 根據(jù)需要構(gòu)建 rdb，并將 rdb 及復(fù)制緩沖發(fā)送給 slave。
對于增量復(fù)制，slave 接下來就等待接受 master 傳來的復(fù)制緩沖及新增的寫指令，進(jìn)行數(shù)據(jù)同步。
而對于全量同步，slave 會首先進(jìn)行，嵌套復(fù)制的清理工作，比如 slave 當(dāng)前還有嵌套的 子slave，則該 slave 會關(guān)閉嵌套 子slave 的所有連接，并清理自己的復(fù)制積壓緩沖。
然后，slave 會構(gòu)建臨時(shí) rdb 文件，并從 master 連接中讀取 rdb 的實(shí)際數(shù)據(jù)，寫入 rdb 中。在寫 rdb 文件時(shí)，每寫 8M，就會做一個(gè) fsync操作， 刷新文件緩沖。當(dāng)接受 rdb 完畢則將 rdb 臨時(shí)文件改名為 rdb 的真正名字。
接下來，slave 會首先清空老數(shù)據(jù)，即刪除本地所有 DB 中的數(shù)據(jù)，并暫時(shí)停止從 master 繼續(xù)接受數(shù)據(jù)。然后，slave 就開始全力加載 rdb 恢復(fù)數(shù)據(jù)，將數(shù)據(jù)從 rdb 加載到內(nèi)存。
在 rdb 加載完畢后，slave 重新利用與 master 的連接 socket，創(chuàng)建與 master 連接的 client，并在此注冊讀事件，可以開始接受 master 的寫指令了。
此時(shí)，slave 還會將 master 的 replid 和復(fù)制偏移設(shè)為自己的復(fù)制 id 和復(fù)制偏移 offset，并將自己的 replid2 清空，因?yàn)椋瑂lave 的所有嵌套 子slave 接下來也需要進(jìn)行全量復(fù)制。
最后，slave 就會打開 aof 文件，在接受 master 的寫指令后，執(zhí)行完畢并寫入到自己的 aof 中。
相比之前的 sync，psync2 優(yōu)化很明顯。在短時(shí)間斷開連接、slave 重啟、切主等多種場景，只要延遲不太久，復(fù)制偏移仍然在復(fù)制積壓緩沖，均可進(jìn)行增量同步。
master 不用構(gòu)建并發(fā)送巨大的 rdb，可以大大減輕 master 的負(fù)荷和網(wǎng)絡(luò)帶寬的開銷。同時(shí)，slave 可以通過輕量的增量復(fù)制，實(shí)現(xiàn)數(shù)據(jù)同步，快速恢復(fù)服務(wù)，減少系統(tǒng)抖動。
但是，psync 依然嚴(yán)重依賴于復(fù)制緩沖積壓，太大會占用過多內(nèi)存，太小會導(dǎo)致頻繁的全量復(fù)制。而且，由于內(nèi)存限制，即便設(shè)置相對較大的復(fù)制緩沖區(qū)，在 slave 斷開連接較久時(shí)，仍然很容易被復(fù)制緩沖積壓沖刷，從而導(dǎo)致全量復(fù)制。
