在使用Redis的時候首先開始是從單台Redis伺服器開始，随着業務和使用者量的增長，單機會暴漏一些問題，比如單台伺服器的響應達到了上限、Redis伺服器當機所有請求全部越過緩存等等一系列問題。
那麼我們最簡單的就是有一個備用的Redis伺服器，當主伺服器挂了從伺服器就頂替主伺服器繼續服務，提高可用性。
我們擁有了主從兩台Redis伺服器之後，當主伺服器挂掉之後從伺服器就替換上去繼續為我們服務，原來的主伺服器恢複正常後我們兩台伺服器的資料又不一樣了，那麼我們如何保證這兩台伺服器的資料一緻性問題呢呢？前面我們提到過CAP定理和BASE理論，我們知道在分布式、叢集環境中我們需要保證資料一緻性。是以我們這裡得使用主從同步，或者是如果我們伺服器數量特别多，我們可以減輕主伺服器的同步壓力，可以使用從從同步。下面我們來介紹Redis支援的幾種同步方式。
增量同步
我們知道Redis增量備份是通過儲存執行指令來備份的，那麼同步的時候我們也可以如此。主節點會将那些對自己的狀态産生修改性影響的指令記錄在本地的記憶體buffer中，然後異步将buffer中的指令同步到從節點，從節點一邊執行同步的指令流來達到和主節點一樣的狀态，一邊向主節點回報自己同步到哪裡了（偏移量） 。
但是記憶體的buffer是有限的，是以Redis主節點不能将所有的指令都記錄在記憶體buffer中，Redis的複制記憶體buffer是一個定長的環形數組，如果數組内容滿了，就會從頭開始覆寫前面的内容；如果因為網絡狀況不好，從節點在短時間内無法和主節點進行同步，那麼當網絡狀況恢複肘，Redis的主節點中那些沒有同步的指令在buffer中有可能已經被後續的指令覆寫掉了。
從節點将無法直接通過指令流來進行同步，這個時候就需要用到更加複雜的同步機制一一快照同步。
快照同步
快照同步既全量同步，就是把整個Redis資料庫快照發送給從節點進行同步，成功後接下來的動作就是增量同步了，是以快照同步是一個非常耗資源的同步方式，這裡注意的是新增加從節點是需要先進行快照同步的。
過程：
- 先将主節點的資料先bgsave
- 将這個快照儲存在磁盤上，重寫開啟一個socket線程
- 通過socket線程可以發送快照給子節點，此時的快照是所有子節點共享的
- 子節點同步
這裡注意一個問題：當我們進行快照同步的時候，增量同步也在進行，當增量同步的資料被覆寫後還會進行快照同步，如此反複形成一個死循環。
無盤複制
我們上面提到了在快照同步的時候會執行增量同步，這裡還有一個沒關注的就是Redis的AOF增量同步問題。
當主節點進行快照同步時是先把這個快照儲存到磁盤中，然後通過子線程共享檔案到從節點，這裡會進行檔案的IO操作，這個操作是非常耗時的，在非SSD磁盤中存儲時快照同步會對系統産生較大的負載，此時剛好主節點到了執行AOF備份操作，但是這兩者并不能同時進行，是以AOF操作是會被延遲執行的，這樣會嚴重影響主節點的執行效率，是以在Redis2.8版本之後支援無盤複制。
無盤複制是指主伺服器直接通過套接字将快照内容發送到從節點，生成快照是一個周遊的過程，主節點會一邊周遊記憶體，一邊将序列化的内容發送到從節點，從節點先将接收到的内容存儲到磁盤檔案中，再進行一次性加載。
同步複制
無盤複制屬于一種異步的方式，Redis3.0提供了一種同步複制的指令——wait，確定系統強一緻性。wait提供兩個參數，第一個參數是從節點的數量，第二個參數是時間，以毫秒為機關。
等待wait指令之前的所有寫操作同步到N個從節點最多等待T毫秒時間。如果時間=0， 表示無限等待直至N個從節點同步完成 。
注意：如果時間等于0，剛好有個節點掉線了，那麼這裡會一直等待，阻塞伺服器。
> set key value OK > wait 1 0 (integer) 1
總結一下：
- 同步類型有主從同步、從從同步
- 同步方式有：增量同步、快照同步、無盤複制、同步複制
- 增量同步記憶體中的buffer環形數組滿了會覆寫，而主節點會執行快照同步
- 新添加從節點會使用快照同步
- 快照同步過程：先執行bgsave把快照資訊放入磁盤，并且開啟子線程将快照共享，發送至從節點進行同步
- 快照同步的同時也會進行增量同步，如果增量同步已經被覆寫則會執行快照同步，産生死循環
- 為了減小主節點的壓力，當啟用同步時資料不經過磁盤直接通過套接字将快照資料同步到從節點
一名正在搶救的coder
筆名：mangolove
CSDN位址：https://blog.csdn.net/mango_love
GitHub位址：https://github.com/mangoloveYu
