1.主寫存儲器快照
save命令調度rdbSave函數，該函數將阻塞主線程的工作。當快照很大時，它會對性能產生很大影響，並且會間歇性地暫停服務。所以主控最好不要寫內存快照。
2.AOF大師堅持不懈
如果不重寫AOF文件，這種持久化方法對性能的影響最小，但AOF文件會繼續增長，過多的AOF文件會影響主重啟的恢復速度。
3.主機調用BGREWRITEAOF
Master調用BGREWRITEAOF重寫AOF文件，重寫時會占用大量CPU和內存資源，導致服務負載高，服務暫停時間短。
以下是我壹個實際項目的情況。大致情況如下:壹個主，四個從，沒有分片機制，只有讀寫分離，主負責寫操作和AOF日誌備份，AOF文件5G左右，從負責讀操作。當Master調用BGREWRITEAOF時，主從的負載會突然急劇增加。大師的寫請求基本沒有回應，持續了5分鐘左右。從機的讀取請求太晚，無法及時響應。主服務器和從服務器的負載圖如下:
主服務器負載:
從屬服務器負載:
上面的情況是不會發生的，也是不應該發生的，因為以前主控的這臺機器是從機，上面有壹個shell timer任務叫BGREWRITEAOF每天早上10重寫AOF文件。後來因為主機宕機，備份從機被切為主機，但是定時器任務忘記刪除了，導致了上面的悲慘情況。幾天後還是找到了原因。
將no-appendfsync-on-rewrite的配置設置為yes可以緩解這個問題。設置為yes表示重寫時新的寫操作不是fsync，暫時存儲在內存中，重寫完成後再寫。最好不要開啟Master的AOF備份功能。
4.4的性能問題。Redis主從復制。
從機對主機的第壹次同步是這樣實現的:從機向主機發送同步請求，主機先轉儲rdb文件，然後將rdb文件完整傳輸給從機，再由主機將緩存的命令轉發給從機，初始同步完成。第二種以及後續的同步實現是:Master將變量的快照實時地依次直接發送給Slave。無論是什麽原因導致從設備和主設備斷開並重新連接，上述過程都會重復。Redis的主從復制基於內存快照的持久性。只要有從，就會有內存快照。雖然Redis宣稱主從復制是非阻塞的，但是因為Redis使用的是單線程服務，如果主快照文件很大，第壹次完整傳輸需要很長時間，文件傳輸過程中主可能無法提供服務，這就意味著服務會被中斷，對於關鍵服務來說也是很可怕的。
以上1.2.3.4的根本原因是系統io瓶頸，即硬盤讀寫不夠快，主進程fsync()/write()操作受阻。
5.單點故障問題
目前Redis的主從復制還不夠成熟，存在明顯的單點故障。目前這個問題只能靠自我解決，比如主動復制，代理以從代主。這也是Redis作者目前的優先任務之壹。作者的解決方法簡單而優雅。詳情請見Redis Sentinel設計稿？
摘要
Master最好不要做任何持久化的工作，包括內存快照和AOF日誌文件，尤其是不要為了持久化而啟用內存快照。
如果數據是關鍵的，從站啟動AOF來備份數據，策略是每秒同步壹次。
為了主從復制的速度和連接的穩定性，主從應該在同壹個局域網內。
盡量避免向壓力大的主庫添加從庫。
對於主的穩定性，主從復制不使用圖形結構，而是使用單向鏈表結構更加穩定，即主從關系為:主