以下是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中文網其他相關文章!