Redis設計與實作知識點總結-主從複制

複制

使用者可以通過執行SLAVEOF指令或者設定其選項，讓一個伺服器去複制另一個伺服器。這樣形成了簡易化叢集。

在2.8版本以前主從複制的機制是：

從伺服器主動請求複制，主伺服器執行BGSAVE指令，将生成的RDB檔案，發送給從伺服器，并在此時使用一個緩沖區緩沖生成RDB檔案以後沒有寫入的指令。

從伺服器接受到RDB檔案進行資料的更新。 然後接受主伺服器傳來的緩沖區的指令，執行進行同步處理。

複制斷線問題解決方法：

當從伺服器在複制中重新開機會重新向伺服器發送一個指令提示主伺服器繼續複制，而主伺服器會重新生成RDB檔案等操作，最後将檔案發送給從伺服器。

從這種方法中我們可以得出，主伺服器做了兩次生成RDB操作，而且，兩次RDB檔案裡面相差的資料不是很大(假設在正常使用的情況下，而非這一秒添加大量資料，下一秒删除大量資料這種極端情況下)，是以這樣及其浪費主伺服器的性能。

自2.8以後的版本：

為了解決斷線重複生成RDB檔案造成的低效問題。Redis使用了新的指令來進行提示主伺服器我又連上了。

部分重同步機制，當從伺服器在斷線重連後，主伺服器将主從伺服器連接配接斷開期間執行的寫指令發送給從伺服器，而從伺服器隻需要執行斷開期間丢失的指令即可。

部分重同步機制，原理為主從伺服器分别維護一個複制偏移量。

每次主伺服器向從伺服器傳播N個位元組時，會将自己的複制偏移量加上N。

從伺服器每次收到請求後，會将自己的複制偏移量也加上N

這樣，如果主從伺服器處于一緻的狀态，則複制偏移量是相同的。

我們考慮這麼一個問題，當主節點向從節點發送一個幾個位元組的資料，而從伺服器斷線了，這時候别的從伺服器能夠接受資料并成功傳回收到了。當從伺服器上線後資料肯定與主伺服器不一緻性，那麼這時候應該執行全部複制同不，還是部分重同步功能那？

在主伺服器發送指令到從伺服器的時候，自己會将指令發送到一個自己維護的緩沖區中，緩沖區的大小為1MB使用了FIFO隊列的結構。是以我們可以了解到，如果從服務在這個緩沖區中查找自己的複制偏移量，如果找的了就使用部分重同步，如果沒有找到就實行完全同步。

伺服器ID

從伺服器和主伺服器都儲存着一個ID，當從伺服器與主伺服器一緻時，說命從伺服器是這個主伺服器上的從節點。

在叢集中，從伺服器預設每秒一次的頻率告知主伺服器自己的狀态以及複制偏移量。