Redis 常見的效能問題和解決方案

參考網站:http://blog.nosqlfan.com/html/4077.html

本文來自溫柔一刀的分享，介紹了他在實際工作中遇到的一些Redis問題以及對應的規避和解決方案，如果你也在用Redis，那麼可能其中有一些經驗可供參考。

原文連結：http://zhupan.iteye.com/blog/1576108 1.Master寫記憶體快照

save命令調度rdbSave函數，會阻塞主線程的工作，當快照比較大時對效能影響是非常大的，會間斷性暫停服務，所以Master最好不要寫記憶體快照。 2.Master AOF持久化

如果不重寫AOF檔案，這個持久化方式對效能的影響是最小的，但是AOF檔案會不斷增大，AOF檔案過大會影響Master重啟的恢複速度。 3.Master調用BGREWRITEAOF

Master調用BGREWRITEAOF重寫AOF檔案，AOF在重寫的時候會佔大量的CPU和記憶體資源，導致服務load過高，出現短暫服務暫停現象。

下面是我的一個實際項目的情況，大概情況是這樣的：一個Master，4個Slave，沒有Sharding機制，僅是讀寫分離，Master負責寫入操作和AOF記錄備份，AOF檔案大概5G，Slave負責讀操作，當Master調用BGREWRITEAOF時，Master和Slave負載會突然陡增，Master的寫入請求基本上都不響應了，持續了大概5分鐘，Slave的讀請求過也半無法及時響應，Master和Slave的伺服器負載圖如下：

Master Server load：

Slave server load：

上面的情況本來不會也不應該發生的，是因為以前Master的這個機器是Slave，在上面有一個shell定時任務在每天的上午10點調用BGREWRITEAOF重寫AOF檔案，後來由於Master機器down了，就把備份的這個Slave切成Master了，但是這個定時任務忘記刪除了，就導致了上面悲劇情況的發生，原因還是找了幾天才找到的。

將no-appendfsync-on-rewrite的配置設為yes可以緩解這個問題，設定為yes表示rewrite期間對新寫操作不fsync，暫時存在記憶體中，等rewrite完成後再寫入。最好是不開啟Master的AOF備份功能。 4.Redis主從複製的效能問題

第一次Slave向Master同步的實現是：Slave向Master發出同步請求，Master先dump出rdb檔案，然後將rdb檔案全量傳輸給slave，然後Master把緩衝的命令轉寄給Slave，初次同步完成。第二次以及以後的同步實現是：Master將變數的快照直接即時依次發送給各個Slave。不管什麼原因導致Slave和Master斷開重連都會重複以上過程。Redis的主從複製是建立在記憶體快照的持久化基礎上，只要有Slave就一定會有記憶體快照發生。雖然Redis宣稱主從複製無阻塞，但由於Redis使用單線程服務，如果Master快照檔案比較大，那麼第一次全量傳輸會耗費比較長時間，且檔案傳輸過程中Master可能無法提供服務，也就是說服務會中斷，對於關鍵服務，這個後果也是很可怕的。

以上1.2.3.4根本問題的原因都離不開系統io瓶頸問題，也就是硬碟讀寫速度不夠快，主進程 fsync()/write() 操作被阻塞。 5.單點故障問題

由於目前Redis的主從複製還不夠成熟，所以存在明顯的單點故障問題，這個目前只能自己做方案解決，如：主動複製，Proxy實現Slave對Master的替換等，這個也是Redis作者目前比較優先的任務之一，作者的解決方案思路簡單優雅，詳情可見 Redis Sentinel design draft http://redis.io/topics/sentinel-spec。 總結 Master最好不要做任何持久化工作，包括記憶體快照和AOF記錄檔，特別是不要啟用記憶體快照做持久化。 如果資料比較關鍵，某個Slave開啟AOF備份資料，策略為每秒同步一次。 為了主從複製的速度和串連的穩定性，Slave和Master最好在同一個區域網路內。 盡量避免在壓力較大的主庫上增加從庫 為了Master的穩定性，主從複製不要用圖狀結構，用單向鏈表結構更穩定，即主從關係為：Master<–Slave1<–Slave2<–Slave3…….，這樣的結構也方便解決單點故障問題，實現Slave對Master的替換，也即，如果Master掛了，可以立馬啟用Slave1做Master，其他不變。