978
redis性能問題和解決方案
redis性能問題和解決方案：
1.Master寫內存快照，save命令調度rdbSave函數，會阻塞主線程的工作，當快照比較大時對性能影響是非常大的，會間斷性暫停服務，所以Master最好不要寫內存快照。
2.Master AOF持久化，如果不重寫AOF文件，這個持久化方式對性能的影響是最小的，但是AOF文件會不斷增大，AOF文件過大會影響Master重啟的恢複速度。
3.Master調用BGREWRITEAOF重寫AOF文件，AOF在重寫的時候會占大量的CPU和內存資源，導致服務load過高，出現短暫服務暫停現象。
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 https://redis.io/topics/sentinel-spec。
總結：
1.Master最好不要做任何持久化工作，包括內存快照和AOF日誌文件，特別是不要啟用內存快照做持久化。
2.如果數據比較關鍵，某個Slave開啟AOF備份數據，策略為每秒同步一次。
3.為了主從複製的速度和連接的穩定性，Slave和Master最好在同一個局域網內。
4.盡量避免在壓力較大的主庫上增加從庫
5.為了Master的穩定性，主從複製不要用圖狀結構，用單向鏈表結構更穩定，即主從關係為：Master<--Slave1<--Slave2<--Slave3.......，這樣的結構也方便解決單點故障問題，實現Slave對Master的替換，也即，如果Master掛了，可以立馬啟用Slave1做Master，其他不變。
最後更新：2017-11-12 20:04:45