大家好，我是小林哥，又來圖解 Redis 啦。
我在前兩篇已經給大家圖解了 AOF 和 RDB，這兩個持久化技術保證了即使在服務器重啓的情況下也不會丟失數據（或少量損失）。
不過，由於數據都是存儲在一臺服務器上，如果出事就完犢子了，比如：
- 如果服務器發生了宕機，由於數據恢復是需要點時間，那麼這個期間是無法服務新的請求的；
- 如果這臺服務器的硬盤出現了故障，可能數據就都丟失了。
要避免這種單點故障，最好的辦法是將數據備份到其他服務器上，讓這些服務器也可以對外提供服務，這樣即使有一臺服務器出現了故障，其他服務器依然可以繼續提供服務。
多臺服務器要保存同一份數據，這裏問題就來了。
這些服務器之間的數據如何保持一致性呢？數據的讀寫操作是否每臺服務器都可以處理？
Redis 提供了主從複製模式，來避免上述的問題。
這個模式可以保證多臺服務器的數據一致性，且主從服務器之間採用的是「讀寫分離」的方式。
主服務器可以進行讀寫操作，當發生寫操作時自動將寫操作同步給從服務器，而從服務器一般是隻讀，並接受主服務器同步過來寫操作命令，然後執行這條命令。
也就是說，所有的數據修改只在主服務器上進行，然後將最新的數據同步給從服務器，這樣就使得主從服務器的數據是一致的。
同步這兩個字說的簡單，但是這個同步過程並沒有想象中那麼簡單，要考慮的事情不是一兩個。
我們先來看看，主從服務器間的第一次同步是如何工作的？
第一次同步
多臺服務器之間要通過什麼方式來確定誰是主服務器，或者誰是從服務器呢？
我們可以使用 replicaof（Redis 5.0 之前使用 slaveof）命令形成主服務器和從服務器的關係。
比如，現在有服務器 A 和 服務器 B，我們在服務器 B 上執行下面這條命令：
# 服務器 B 執行這條命令
replicaof <服務器 A 的 IP 地址> <服務器 A 的 Redis 端口號>
接着，服務器 B 就會變成 服務器 A 的「從服務器」，然後與主服務器進行第一次同步。
主從服務器間的第一次同步的過程可分爲三個階段：
- 第一階段是建立鏈接、協商同步；
- 第二階段是主服務器同步數據給從服務器；
- 第三階段是主服務器發送新寫操作命令給從服務器。
爲了讓你更清楚瞭解這三個階段，我畫了一張圖。
接下來，我在具體介紹每一個階段都做了什麼。
第一階段：建立鏈接、協商同步
執行了 replicaof 命令後，從服務器就會給主服務器發送 psync 命令，表示要進行數據同步。
psync 命令包含兩個參數，分別是主服務器的 runID 和複製進度 offset。
- runID，每個 Redis 服務器在啓動時都會自動生產一個隨機的 ID 來唯一標識自己。當從服務器和主服務器第一次同步時，因爲不知道主服務器的 run ID，所以將其設置爲 "?"。
- offset，表示複製的進度，第一次同步時，其值爲 -1。
主服務器收到 psync 命令後，會用 FULLRESYNC 作爲響應命令返回給對方。
並且這個響應命令會帶上兩個參數：主服務器的 runID 和主服務器目前的複製進度 offset。從服務器收到響應後，會記錄這兩個值。
FULLRESYNC 響應命令的意圖是採用全量複製的方式，也就是主服務器會把所有的數據都同步給從服務器。
所以，第一階段的工作時爲了全量複製做準備。
那具體怎麼全量同步呀呢？我們可以往下看第二階段。
第二階段：主服務器同步數據給從服務器
接着，主服務器會執行 bgsave 命令來生成 RDB 文件，然後把文件發送給從服務器。
從服務器收到 RDB 文件後，會先清空當前的數據，然後載入 RDB 文件。
這裏有一點要注意，主服務器生成 RDB 這個過程是不會阻塞主線程的，也就是說 Redis 依然可以正常處理命令。
但是這期間的寫操作命令並沒有記錄到剛剛生成的 RDB 文件中，這時主從服務器間的數據就不一致了。
那麼爲了保證主從服務器的數據一致性，主服務器會將在 RDB 文件生成後收到的寫操作命令，寫入到 replication buffer 緩衝區裏。
第三階段：主服務器發送新寫操作命令給從服務器
在主服務器生成的 RDB 文件發送後，然後將 replication buffer 緩衝區裏所記錄的寫操作命令發送給從服務器，然後從服務器重新執行這些操作。
至此，主從服務器的第一次同步的工作就完成了。
命令傳播
主從服務器在完成第一次同步後，雙方之間就會維護一個 TCP 連接。
後續主服務器可以通過這個連接繼續將寫操作命令傳播給從服務器，然後從服務器執行該命令，使得與主服務器的數據庫狀態相同。
而且這個連接是長連接的，目的是避免頻繁的 TCP 連接和斷開帶來的性能開銷。
上面的這個過程被稱爲基於長連接的命令傳播，通過這種方式來保證第一次同步後的主從服務器的數據一致性。
分攤主服務器的壓力
在前面的分析中，我們可以知道主從服務器在第一次數據同步的過程中，主服務器會做兩件耗時的操作：生成 RDB 文件和傳輸 RDB 文件。
主服務器是可以有多個從服務器的，如果從服務器數量非常多，而且都與主服務器進行全量同步的話，就會帶來兩個問題：
- 由於是通過 bgsave 命令來生成 RDB 文件的，那麼主服務器就會忙於使用 fork() 創建子進程，如果主服務器的內存數據非大，在執行 fork() 函數時是會阻塞主線程的，從而使得 Redis 無法正常處理請求；
- 傳輸 RDB 文件會佔用主服務器的網絡帶寬，會對主服務器響應命令請求產生影響。
這種情況就好像，剛創業的公司，由於人不多，所以員工都歸老闆一個人管，但是隨着公司的發展，人員的擴充，老闆慢慢就無法承擔全部員工的管理工作了。
要解決這個問題，老闆就需要設立經理職位，由經理管理多名普通員工，然後老闆只需要管理經理就好。
Redis 也是一樣的，從服務器可以有自己的從服務器，我們可以把擁有從服務器的從服務器當作經理角色，它不僅可以接收主服務器的同步數據，自己也可以同時作爲主服務器的形式將數據同步給從服務器，組織形式如下圖：
通過這種方式，主服務器生成 RDB 和傳輸 RDB 的壓力可以分攤到充當經理角色的從服務器。
那具體怎麼做到的呢？
其實很簡單，我們在「從服務器」上執行下面這條命令，使其作爲目標服務器的從服務器：
replicaof <目標服務器的IP> 6379
此時如果目標服務器本身也是「從服務器」，那麼該目標服務器就會成爲「經理」的角色，不僅可以接受主服務器同步的數據，也會把數據同步給自己旗下的從服務器，從而減輕主服務器的負擔。
增量複製
主從服務器在完成第一次同步後，就會基於長連接進行命令傳播。
可是，網絡總是不按套路出牌的嘛，說延遲就延遲，說斷開就斷開。
如果主從服務器間的網絡連接斷開了，那麼就無法進行命令傳播了，這時從服務器的數據就沒辦法和主服務器保持一致了，客戶端就可能從「從服務器」讀到舊的數據。
那麼問題來了，如果此時斷開的網絡，又恢復正常了，要怎麼繼續保證主從服務器的數據一致性呢？
在 Redis 2.8 之前，如果主從服務器在命令同步時出現了網絡斷開又恢復的情況，從服務器就會和主服務器重新進行一次全量複製，很明顯這樣的開銷太大了，必須要改進一波。
所以，從 Redis 2.8 開始，網絡斷開又恢復後，從主從服務器會採用增量複製的方式繼續同步，也就是隻會把網絡斷開期間主服務器接收到的寫操作命令，同步給從服務器。
網絡恢復後的增量複製過程如下圖：
主要有三個步驟：
- 從服務器在恢復網絡後，會發送 psync 命令給主服務器，此時的 psync 命令裏的 offset 參數不是 -1；
- 主服務器收到該命令後，然後用 CONTINUE 響應命令告訴從服務器接下來採用增量複製的方式同步數據；
- 然後主服務將主從服務器斷線期間，所執行的寫命令發送給從服務器，然後從服務器執行這些命令。
那麼關鍵的問題來了，主服務器怎麼知道要將哪些增量數據發送給從服務器呢？
答案藏在這兩個東西里：
- repl_backlog_buffer，是一個「環形」緩衝區，用於主從服務器斷連後，從中找到差異的數據；
- replication offset，標記上面那個緩衝區的同步進度，主從服務器都有各自的偏移量，主服務器使用 master_repl_offset 來記錄自己「寫」到的位置，從服務器使用 slave_repl_offset 來記錄自己「讀」到的位置。
那repl_backlog_buffer 緩衝區是什麼時候寫入的呢？
在主服務器進行命令傳播時，不僅會將寫命令發送給從服務器，還會將寫命令寫入到 repl_backlog_buffer 緩衝區裏，因此 這個緩衝區裏會保存着最近傳播的寫命令。
網絡斷開後，當從服務器重新連上主服務器時，從服務器會通過 psync 命令將自己的複製偏移量 slave_repl_offset 發送給主服務器，主服務器根據自己的 master_repl_offset 和 slave_repl_offset 之間的差距，然後來決定對從服務器執行哪種同步操作：
- 如果判斷出從服務器要讀取的數據還在 repl_backlog_buffer 緩衝區裏，那麼主服務器將採用增量同步的方式；
- 相反，如果判斷出從服務器要讀取的數據已經不存在
repl_backlog_buffer 緩衝區裏，那麼主服務器將採用全量同步的方式。
當主服務器在 repl_backlog_buffer 中找到主從服務器差異（增量）的數據後，就會將增量的數據寫入到 replication buffer 緩衝區，這個緩衝區我們前面也提到過，它是緩存將要傳播給從服務器的命令。
repl_backlog_buffer 緩行緩衝區的默認大小是 1M，
並且由於它是一個環形緩衝區，所以當緩衝區寫滿後，主服務器繼續寫入的話，就會覆蓋之前的數據。
因此，當主服務器的寫入速度遠超於從服務器的讀取速度，緩衝區的數據一下就會被覆蓋，在網絡恢復時，如果從服務器想讀的數據已經被覆蓋了，主服務器就會採用全量同步，這個方式比增量同步的性能損耗要大很多。
因此，爲了避免在網絡恢復時，主服務器頻繁地使用全量同步的方式，我們應該調整下 repl_backlog_buffer 緩衝區大小，儘可能的大一些，減少出現從服務器要讀取的數據被覆蓋的概率，從而使得主服務器採用增量同步的方式。
那 repl_backlog_buffer 緩衝區具體要調整到多大呢？
repl_backlog_buffer 最小的大小可以根據這面這個公式估算。
我來解釋下這個公式的意思：
- second 爲從服務器斷線後重新連接上主服務器所需的平均 時間(以秒計算)。
- write_size_per_second 則是主服務器平均每秒產生的寫命令數據量大小。
舉個例子，如果主服務器平均每秒產生 1 MB 的寫命令，而從服務器斷線之後平均要 5 秒才能重新連接主服務器。
那麼 repl_backlog_buffer 大小就不能低於 5 MB，否則新寫地命令就會覆蓋舊數據了。
當然，爲了應對一些突發的情況，可以將 repl_backlog_buffer 的大小設置爲此基礎上的 2 倍，也就是 10 MB。
關於 repl_backlog_buffer 大小修改的方法，只需要修改配置文件裏下面這個參數項的值就可以。
repl-backlog-size 1mb
總結
主從複製共有三種模式：全量複製、基於長連接的命令傳播、增量複製。
主從服務器第一次同步的時候，就是採用全量複製，此時主服務器會兩個耗時的地方，分別是生成 RDB 文件和傳輸 RDB 文件。爲了避免過多的從服務器和主服務器進行全量複製，可以把一部分從服務器升級爲「經理角色」，讓它也有自己的從服務器，通過這樣可以分攤主服務器的壓力。
第一次同步完成後，主從服務器都會維護着一個長連接，主服務器在接收到寫操作命令後，就會通過這個連接將寫命令傳播給從服務器，來保證主從服務器的數據一致性。
如果遇到網絡斷開，增量複製就可以上場了，不過這個還跟 repl_backlog_size 這個大小有關係。
如果它配置的過小，主從服務器網絡恢復時，可能發生「從服務器」想讀的數據已經被覆蓋了，那麼這時就會導致主服務器採用全量複製的方式。所以爲了避免這種情況的頻繁發生，要調大這個參數的值，以降低主從服務器斷開後全量同步的概率。
參考資料
- 《Redis核心技術與實戰》
- 《Redis設計與實現》
- 《Redis源碼分析》
往期圖解
我是小林，今天的你，比昨天更博學了嗎？
我們下次見啦。