Redis 主庫從庫如何保證資料一致

redis核心技術與實戰 - 06

資料盡量少丟失；通過 aof 和 rdb 保證

服務盡量少中斷；通過增加副本冗餘量來保證，將乙份資料同時儲存在多個例項上。即使有乙個例項出現了故障，需要過一段時間才能恢復，其他例項也可以對外提供服務，不會影響業務使用。

一、主從庫模式（主從複製讀寫分離 --> 以相對小開銷保證多例項資料一致）

二、主從庫同步過程：

1、主從庫第一次同步 (通過rdb快照完成全量複製)

2、主從庫實時同步（基於長連線的實時命令傳播）

3、【主 - 從 - 從】模式（緩解主庫多次生成rdb和傳輸rdb的開銷）

4、主從庫間網路斷了怎麼辦？（基於斷開點進行增量複製）

增量複製：（通過repl_backlog_buffer 環形緩衝區來記錄主庫新增命令位置，從庫已讀取位置，對位置差間內容進行重寫。）

環形緩衝區的問題：（大小會影響記錄的準確性，repl_backlog_size引數調節大小）

三、建議（乙個 redis 例項的資料庫不要太大）

為保證服務盡量少中斷而提供多例項，這麼多副本，它們之間的資料如何保持一致呢？資料讀寫操作可以發給所有的例項嗎？

redis 提供了主從庫模式，以保證資料副本的一致，主從庫之間採用的是讀寫分離的方式，以減少為保證各個例項上資料一致性的開銷。

主從庫之間採用的是讀寫分離的方式：

乙個資料的寫操作要保持在多個例項上一致，就要涉及到加鎖、例項間協商是否完成修改等一系列操作，但這會帶來鉅額的開銷，當然是不太能接受的。而主從庫模式一旦採用了讀寫分離，所有資料的修改只會在主庫上進行，不用協調三個例項。

主庫有了最新的資料後，會同步給從庫，這樣，主從庫的資料就是一致的。

一旦主從庫完成了全量複製，它們之間就會一直維護乙個網路連線，主庫會通過這個連線將後續陸續收到的命令操作再同步給從庫，這個過程也稱為基於長連線的命令傳播，可以避免頻繁建立連線的開銷。

第一階段全量複製中，對於主庫來說，需要完成兩個耗時的操作：生成 rdb 檔案和傳輸 rdb 檔案。

如果從庫數量很多，而且都要和主庫進行全量複製的話，就會導致主庫忙於 fork 子程序生成 rdb 檔案，進行資料全量同步。fork 這個操作會阻塞主線程處理正常請求，從而導致主庫響應應用程式的請求速度變慢。此外，傳輸 rdb 檔案也會占用主庫的網路頻寬，同樣會給主庫的資源使用帶來壓力。

通過「主 - 從 - 從」模式將主庫生成 rdb 和傳輸 rdb 的壓力，以級聯的方式分散到從庫上。

在 redis 2.8 之前，如果主從庫在命令傳播時出現了網路閃斷，那麼，從庫就會和主庫重新進行一次全量複製，開銷非常大。

從 redis 2.8 開始，網路斷了之後，主從庫會採用增量複製的方式繼續同步。

當主從庫斷連後，主庫會把斷連期間收到的寫操作命令，寫入 replication buffer，同時也會把這些操作命令也寫入 repl_backlog_buffer 這個緩衝區。

因為 repl_backlog_buffer 是乙個環形緩衝區，所以在緩衝區寫滿後，主庫會繼續寫入，此時，就會覆蓋掉之前寫入的操作。

如果從庫的讀取速度比較慢，就有可能導致從庫還未讀取的操作被主庫新寫的操作覆蓋了，這會導致主從庫間的資料不一致。因此，我們要想辦法避免這一情況，一般而言，我們可以調整 repl_backlog_size 這個引數來控制緩衝區的大小。

緩衝空間的計算公式是：緩衝空間大小 = 主庫寫入命令速度 * 操作大小 - 主從庫間網路傳輸命令速度 * 操作大小。

另外，為了避免多個從庫同時和主庫進行全量複製，給主庫過大的同步壓力，我們也可以採用「主 - 從 - 從」這一級聯模式，來緩解主庫的壓力。