Redis學習七：Redis的持久化-總結(Which one)
阿新 • • 發佈：2018-09-27
會有 原始的 實現 丟失 span save 在服務器 which 方式
作者建議不要，因為RDB更適合用於備份數據庫(AOF在不斷變化不好備份)，
快速重啟，而且不會有AOF可能潛在的bug，留著作為一個萬一的手段。
如果不Enable AOF ，僅靠Master-Slave Replication 實現高可用性也可以。能省掉一大筆IO也減少了rewrite時帶來的系統波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的數據，啟動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個。新浪微博就選用了這種架構
1.官網建議
2.RDB持久化方式能夠在指定的時間間隔能對你的數據進行快照存儲
3.AOF持久化方式記錄每次對服務器寫的操作,當服務器重啟的時候會重新執行這些
命令來恢復原始的數據,AOF命令以redis協議追加保存每次寫的操作到文件末尾.
Redis還能對AOF文件進行後臺重寫,使得AOF文件的體積不至於過大
4.只做緩存：如果你只希望你的數據在服務器運行的時候存在,你也可以不使用任何持久化方式.
5.同時開啟兩種持久化方式
在這種情況下,當redis重啟的時候會優先載入AOF文件來恢復原始的數據,
因為在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集要完整.
RDB的數據不實時，同時使用兩者時服務器重啟也只會找AOF文件。那要不要只使用AOF呢？
作者建議不要，因為RDB更適合用於備份數據庫(AOF在不斷變化不好備份)，
快速重啟，而且不會有AOF可能潛在的bug，留著作為一個萬一的手段。
6.性能建議
因為RDB文件只用作後備用途，建議只在Slave上持久化RDB文件，而且只要15分鐘備份一次就夠了，只保留save 900 1這條規則。
如果Enalbe AOF，好處是在最惡劣情況下也只會丟失不超過兩秒數據，啟動腳本較簡單只load自己的AOF文件就可以了。代價一是帶來了持續的IO，二是AOF rewrite的最後將rewrite過程中產生的新數據寫到新文件造成的阻塞幾乎是不可避免的。只要硬盤許可，應該盡量減少AOF rewrite的頻率，AOF重寫的基礎大小默認值64M太小了，可以設到5G以上。默認超過原大小100%大小時重寫可以改到適當的數值。
如果不Enable AOF ，僅靠Master-Slave Replication 實現高可用性也可以。能省掉一大筆IO也減少了rewrite時帶來的系統波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的數據，啟動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個。新浪微博就選用了這種架構
Redis學習七：Redis的持久化-總結(Which one)