一、解決主從復制問題
當使用Redis作為存儲引擎的時候，并且使用Redis讀寫分離，從機作為讀的情況，從機宕機或者和主機斷開連接都需要重新連接主機，重新連接主機都會觸發全量的主從復制，這時候主機會生成內存快照，主機依然可以對外提供服務，但是作為讀的從機，就無法提供對外服務了，如果數據量大，恢復的時間會相當的長。為了解決Redis主從Copy的問題，有如下兩個解決方案：
主動復制
所謂主動復制，就是業務層雙寫多個Redis，避開Redis自帶的主從復制。但是自己干同步，就會產生一致性問題，為了保證主從一致，需要加入一系列的驗證機制。而且這樣的做法，會降低系統性能。
修改源代碼，支持增量同步
Redis寫AOF文件，關閉Redis rewrite AOF文件功能，為了避免文件過大，可以自己實現文件分割功能。
在業務低峰時期，生成內存快照，并記錄快照時刻AOF所在的點。
當從機重連的時候，從機發送同步命令給主機，主機收到命令后，把最新的快照文件發送給從機，從機從快照文件中恢復，并且獲得了該快照對應的AOF點，從機將AOF點發送給主機，主機將AOF文件中該點之后的所有數據操作同步給從機，達到增量同步的效果。
二、解決擴容問題
Redis作者的思路是：Redis Presharding(http://oldblog.antirez.com/post/redis-presharding.html)
預算設定Redis instances數量，假設實例數量n，n = 機器數*單臺機器redis實例數
后期擴展只需要將舊機器上的部分redis實例遷移到新的機器上，達到平滑擴容。
遷移步驟如下：
在新的機器上創建實例，并且每個實例設置為被遷移實例的從機。
主從復制完成之后，設置程序將新的實例作為主。
停止舊的實例
經過如上步驟之后，舊機器的內存就變大了，最后內存最大為每臺機器一個Redis實例。
按作者文章中所說的，一個機器啟動多個實例，其實并不會耗費太多資源，因為Redis夠輕量，另外多個實例一個接一個的重寫AOF文件或者生成內存快照，可以降低內存的占用，而不影響對外的服務。
