原文連結：http://www.infoq.com/cn/articles/tq-redis-copy-build-scalable-clusterRedis複製流程概述：複製功能：完全建立在基於記憶體快照的持久化策略基礎上。即：無論持久化策略選擇的是什麼，只要用到Redis複製功能，就一定會有記憶體快照發生---->所以，首先要注意系統記憶體容量規劃（原因涉及到Redis磁碟IO問題）Redis 複製流程在slave和Master端各自是一套狀態機流轉。涉及到的狀態資訊是：SlaveREDIS_REPL_NONE

REDIS_REPL_CONNECT REDIS_REPL_CONNECTED 

Master端：REDIS_REPL_WAIT_BGSAVE_START

REDIS_REPL_WAIT_BGSAVE_END REDIS_REPL_SEND_BULK REDIS_REPL_ONLINE

整個狀態機流程過程：1、Slave端在配置檔案中新增slave of指令，於是slave啟動時讀取配置檔案，初始狀態為：REDIS_REPL_CONNECT。2、Slave端在定時任務serverCron（Redis內部的定時器觸發事件）中連線Master，傳送sync命令。然後阻塞等待master傳送回其記憶體塊狀檔案。3、Master收到sync命令，簡單判斷是否有正在進行的記憶體快照子程序，沒有則開始記憶體快照，有則等待結束，當快照完成後會將該檔案傳送給slave端。4、Slave端接收Master發來的記憶體快照檔案，儲存到本地，接收完成後，清空記憶體表。重新讀取Master發來的記憶體快照檔案。重建整個記憶體表資料結構。並最終狀態置位為REDIS_REPL_CONNECTED，---Slave狀態機流轉完成。5、Master 在傳送快照檔案中，接受的任何會改變資料集的命令都先會暫時儲存在Slave網路連線的傳送快取佇列裡——（list資料結構）。。待快照完成後，依次傳送給Slave，之後收到的命令相同處理，並將狀態置位為REDIS_REPL_ONLINE。Redis 複製機制的缺陷Slave從庫連線Master主庫時，Master會進行記憶體快照，然後把快照檔案發給Slave。沒有像MySQL那樣有複製位置的概念——無增量複製，這樣會給整個叢集搭建帶來很多問題：主從庫讀寫分離的配置中，————假如從庫Slave與Master斷開了連線----------------那麼重新連線時，需重新獲取整個Master的快照，Slave重新建立整個記憶體表，----這樣就造成：====一方面Slave恢復的時間會非常慢，另一方面也會給主庫帶來壓力所以基於上述原因：如果Redis需主從複製，那麼最好事先配置好所有的從庫，避免中途再去增加從庫。Cache還是Storage的問題 Redis目前的設計思路——單機版的思路，因為持久化方式不夠成熟，複製機制存在較大缺陷。——那麼Redis應該怎樣定位：Cache還是Storage？？如果是Cache的話，除了那些必須使用Redis的某種資料結構的特殊的業務場景外，Memcache則會更合適；如果作為Storage的話，無法解決Redis的單點問題。即一臺Redis掛掉，就沒有太好的辦法能夠快速的恢復。Redis可擴充套件叢集搭建：主動複製避開Redis複製缺陷——即一次進行多次寫入；解決容量規劃與線上擴容問題。問題：多個Redis例項是啥意思？？？？Redis複製改進思路:暫時先沒看Redis與MySQL的結合：大部分網際網路公司採用MySQL作為資料的主要持久化儲存。這樣設計一種基於MySQL作為主庫，Redis作為高速資料查詢從庫的異構讀寫分離的設計方案。。