Redis只保證最終一致性，網絡正常情況下，從節點努力追趕主節點，從而實現主從狀態一致；如果網絡斷開又恢復後，從節點會採用多種策略去努力趕上主節點，盡力跟主節點保持一致性。
同步策略1：主從同步
支持主從同步、從從同步，只不過從從同步功能是後續版本增加的功能。
同步策略2：增量同步
增量同步指的是指令流，主節點會將對自身狀態產生影響的修改性指令記錄在本地的內存buffer 中，然後異步將buffer中的指令同步到從節點，這樣從節點一邊執行同步的指令流來達到和主節點一樣的狀態，同時一邊主節點反饋自己執行到哪裏了。
但主節點的內存buffer是有限的，所以主庫不能將所有的指令都記錄在內存buffer中。主節點的複製內存buffer是一個定長的環形數組，如果數組內容滿了，就會從頭開始覆蓋前面的內容。這就意味着如果因爲網絡狀況不好，從節點在短時間內無法和主節點進行同步，那麼當網絡狀況恢復時，主節點中那些沒有同步的指令在buffer 中有可能已經被後續的指令覆蓋掉了，從節點將無法直接通過指令流來進行同步。
同步策略3：快照同步
快照同步是一個非常耗費資源的操作，它首先需要在主庫上進行一次bgsave將當前內存的數據全部快照到磁盤文件中，然後再將快照文件的內容全部傳送到從節點。從節點將快照文件接受完畢後，立即執行一次全量加載，加載之前先要將當前內存的數據清空。加載完畢後通知主節點繼續進行增量同步。
在整個快照同步進行的過程中，主節點的複製buffer還在不停的往前移動，如果快照同步的時間過長或者複製 buffer 太小，都會導致同步期間的增量指令在複製buffer中被覆蓋，這樣就會導致快照同步完成後無法進行增量複製，然後會再次發起快照同步，如此極有可能會陷入快照同步的死循環。
所以務必配置一個合適的複製 buffer 大小參數，避免快照複製的死循環。
當從節點剛剛加入到集羣時，它必須先要進行一次快照同步，同步完成後再繼續進行增量同步。
同步策略4：無盤複製
主節點在進行快照同步時，會進行很重的文件IO操作，特別是對於非SSD磁盤存儲時，快照會對系統的負載產生較大影響。特別是當系統正在進行AOF的fsync 操作時如果發生快照，fsync將會被推遲執行，這就會嚴重影響主節點的服務效率。
從Redis 2.8.18版開始支持無盤複製。所謂無盤複製是指主服務器直接通過套接字將快照內容發送到從節點，生成快照是一個遍歷的過程，主節點會一邊遍歷內存，一遍將序列化的內容發送到從節點，從節點還是跟之前一樣，先將接收到的內容存儲到磁盤文件中，再進行一次性加載。
同步策略5：同步複製指令wait
Redis複製是異步進行的，wait指令可以讓異步複製變身同步複製，確保系統的強一致性。該指令是Redis3.0版本以後纔出現的。
wait 提供兩個參數，第一個參數是從庫的數量 N，第二個參數是時間 t，以毫秒爲單位。它表示等待 wait 指令之前的所有寫操作同步到 N 個從庫 (也就是確保N個從庫的同步沒有滯後)，最多等待時間t。如果時間t=0，表示無限等待直到N個從庫同步完成達成一致。
假設此時出現了網絡分區，wait 指令第二個參數時間t=0，主從同步無法繼續進行，wait 指令會永遠阻塞，Redis 服務器將喪失可用性。
