以下是Redis常見的效能問題有哪些？
Master寫記憶體快照，save指令調度rdbSave函數，會阻塞主執行緒的工作，當快照比較大時對效能影響是非常大的，會間斷性暫停服務，所以Master最好不要寫記憶體快照。 （推薦學習：Redis影片教學）
Master AOF持久化，如果不重寫AOF文件，這個持久化方式對效能的影響是最小的，但是AOF文件會不斷增大，AOF文件過大會影響Master重啟的恢復速度。
Master呼叫BGREWRITEAOF重寫AOF文件，AOF在重寫的時候會佔大量的CPU和記憶體資源，導致服務load過高，短暫服務暫停現象。
下面是我的一個實際專案的情況，大概情況是這樣的：
一個Master，4個Slave，沒有Sharding機制，只是讀寫分離，Master負責寫入作業和AOF日誌備份，AOF檔大概5G，Slave負責讀取作業，當Master呼叫BGREWRITEAOF時，Master和Slave負載會突然陡增，Master的寫入請求基本上都回應了，持續了大概5分鐘，Slave的讀請求過半也無法及時回應，上面的情況本來不會也不應該發生的，是因為以前Master的這個機器是Slave，在上面有一個shell定時任務在每天的上午10點調用BGREWRITEAOF重寫AOF文件，後來由於Master機器down了，就把備份的這個Slave切成Master了，但是這個定時任務忘記刪除了，就導致了上面悲劇情況的發生，原因還是找了幾天才找到的。
將no-appendfsync-on-rewrite的配置設為yes可以緩解這個問題，設定為yes表示rewrite期間對新寫入操作不fsync，暫時存在記憶體中，等rewrite完成後再寫入。最好是不開啟Master的AOF備份功能。
Redis主從複製的效能問題，第一次Slave向Master同步的實作是：Slave向Master發出同步請求，Master先dump出rdb文件，然後將rdb文件全量傳送給slave，然後Master把快取的指令轉寄給Slave，初次同步完成。第二次以及以後的同步實作是：Master將變數的快照直接即時依序傳送給各個Slave。不管什麼原因導致Slave和Master斷開重連都會重複以上過程。 Redis的主從複製是建立在記憶體快照的持久化基礎上，只要有Slave就一定會有記憶體快照發生。雖然Redis宣稱主從複製無阻塞，但由於磁碟io的限制，如果Master快照檔案比較大，那麼dump會耗費比較長的時間，這個過程中Master可能無法回應請求，也就是說服務會中斷，對於關鍵服務，這個後果也是很可怕的。
以上1.2.3.4根本問題的原因都離不開系統io瓶頸問題，也就是硬碟讀寫速度不夠快，主程序 fsync()/write() 操作被阻塞。
單點故障問題，由於目前Redis的主從複製還不夠成熟，所以存在明顯的單點故障問題，這個目前只能自己做方案解決，如：主動複製，Proxy實作Slave對Master的替換等，這個也是Redis作者目前比較優先的任務之一。
更多Redis相關技術文章，請造訪Redis資料庫使用入門教學欄位學習！
以上是redis效能有哪些問題的詳細內容。更多資訊請關注PHP中文網其他相關文章！
