Redis持久化（RDB 和 AOF）
一、RDB持久化
RDB（Redis DataBase）：
配置文件中對其的相關配置：
觸發機制：
恢復rdb文件：
優點：
缺點：
二、AOF持久化
AOF（Append Only File）：
配置文件中對其的相關配置：
恢復aof文件：
優點：
缺點：
Redis中的數據存在內存中肯定是不安全的，所以需要將數據進行持久化操作，防止數據丟失造成的危害。
?
一、RDB持久化
RDB（Redis DataBase）：
在指定時間間隔內將內存中的數據快照集體寫入磁盤，也就是Snapshot快照，恢復時將快照文件直接讀到內存中。
Redis會單獨創建（fork）一個子進程來進行持久化，會先將數據寫入一個臨時文件中，待持久化過程都結束，再用這個臨時文件替換上次持久化好的文件。整個過程中，主進程不進行任何IO操作。這就確保了極高的性能。如果需要進行大規模數據的恢復，且對于數據恢復的完整性不是非常敏感，那RDB方式比AOF方式更加高效。RDB的缺點是最后一次持久化后的數據可能丟失。
默認情況下是?RDB，一般不需要修改這個配置！
在主從復制中，rdb就是備用，從機上！
配置文件中對其的相關配置：
1、RDB保存的文件 dump.rdb （在生成環境中經常將rdb文件備份）
2、RDB默認的保存規則：900s中發生一次修改就進行保存
觸發機制：
save的規則滿足情況下，自動觸發rdb規則
執行flushall命令，也會觸發rdb規則
退出redis（shut down 合理退出命令），也會產生rdb文件
備份就自動生成一個 dump.rdb 文件
恢復rdb文件：
只需將rdb文件放在redis啟動目錄就可以，redis啟動的時候會自動檢查dump.rdb 恢復其中的數據！
查看需要存放的位置：config get dir
優點：
適合大規模的數據恢復！（父進程不參與數據的保存恢復，而是fork子進程管理，效率高）
對數據完整性要求不高！（比如300s內更新了9次突然宕機了，那最后的數據沒來得及保存就丟失了）
缺點：
需要一定的時間間隔進行操作！如果redis意外當即，最后一次修改數據就沒
fork進程的時候，會占用一定的資源！
?
二、AOF持久化
AOF（Append Only File）：
以日志的形式將我們的所有命令都記錄下來（寫記錄讀不記錄），秩序罪加文件不可更改文件，redis重啟會去讀該文件重新構建數據，換言之，把這個文件中指令全部再執行一遍。
配置文件中對其的相關配置：
1、保存在 appendonly.aof（默認不開啟，開啟需要手動配置）
2、持久化策略（默認每秒寫一次）
3、重寫規則
默認是文件的無限追加，文件會越來越大！
當文件大小超過64m，fork一個新的進程來講我們的文件進行重寫
?
恢復aof文件：
破壞/損壞 aof 文件后，無法啟動redis（如果默認時aof模式下）
此時，可以用 redis-check-aof 來修復
?
優點：
每次修改都同步，文件的完整性會更好！
沒秒同步一次，可能會丟失一秒的數據！
從不同步，效率最高的！
缺點：
相對于數據文件來說，aof遠遠大于rdb，修復的速度也比rdb慢！
aof運行效率也要比rdb慢，所以redis默認配置是rdb！
性能建議：
因為RDB文件只用作后備用途，建議只在Slave上持久化RDB文件，而且只要15分鐘備份一次就夠 了。
如果Enable AOF ，好處是在最惡劣情況下也只會丟失不超過兩秒數據，啟動腳本較簡單只load自己的 AOF文件就可以了，代價一是帶來了持續的IO，二是AOF rewrite 的最后 將 rewrite過程中產生的新數據寫到新文件造成的阻塞幾乎是不可避免的。
只要硬盤許可，應該盡量減少AOF rewrite的頻率，AOF重寫的基礎大小默認值64M太小了，可以設到5G以上，,默認超過原大小100%大小重寫可以改到適當的數值。
如果不Enable AOF，僅靠 Master-Slave Repllcation 實現高可用性也可以，能省掉一大筆IO，也 減少了rewrite時帶來的系統波動。代價是如果Master/Slave 同時掛了，會丟失十幾分鐘的數據， 啟動腳本也要比較兩個 Master/Slave 中的 RDB文件，載入較新的那個，微博就是這種架構。
?
總結
以上是生活随笔為你收集整理的Redis持久化（RDB 和 AOF）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 以DES的方式实现对称加密，并提供密钥
- 下一篇： 数据库的方向 - 行vs列(转自： IB