共計 2111 個字符，預計需要花費 6 分鐘才能閱讀完成。
這篇文章主要講解了“Redis 的持久化機制采用 RDB 還是 AOF”，文中的講解內(nèi)容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“Redis 的持久化機制采用 RDB 還是 AOF”吧！
RDB1. 什么是 RDB
RDB：每隔一段時間，把內(nèi)存中的數(shù)據(jù)寫入磁盤的臨時文件，作為快照，恢復的時候把快照文件讀進內(nèi)存。如果宕機重啟，那么內(nèi)存里的數(shù)據(jù)肯定會沒有的，那么再次啟動 redis 后，則會恢復。
2. 備份與恢復
內(nèi)存?zhèn)浞?— 磁盤臨時文件
臨時文件 — 恢復到內(nèi)存
3. RDB 優(yōu)劣勢
優(yōu)勢
每隔一段時間備份，全量備份
災備簡單，可以遠程傳輸
子進程備份的時候，主進程不會有任何 io 操作（不會有寫入修改或刪除），保證備份數(shù)據(jù)的的完整性
相對 AOF 來說，當有更大文件的時候可以快速重啟恢復
劣勢
發(fā)生故障是，有可能會丟失最后一次的備份數(shù)據(jù)
子進程所占用的內(nèi)存比會和父進程一模一樣，如會造成 CPU 負擔
由于定時全量備份是重量級操作，所以對于實時備份，就無法處理了。
4. RDB 的配置
保存位置，可以在 redis.conf 自定義：
/user/local/redis/working/dump.rdb
保存機制：
save 900 1
save 300 10
save 60 10000
save 10 3* 如果 1 個緩存更新，則 15 分鐘后備份
* 如果 10 個緩存更新，則 5 分鐘后備份
* 如果 10000 個緩存更新，則 1 分鐘后備份stop-writes-on-bgsave-error
yes：如果 save 過程出錯，則停止寫操作
no：可能造成數(shù)據(jù)不一致
rdbcompression
yes：開啟 rdb 壓縮模式
no：關閉，會節(jié)約 cpu 損耗，但是文件會大，道理同 nginx
rdbchecksum
yes：使用 CRC64 算法校驗對 rdb 進行數(shù)據(jù)校驗，有 10% 性能損耗
no：不校驗
總結(jié)
RDB 適合大量數(shù)據(jù)的恢復，但是數(shù)據(jù)的完整性和一致性可能會不足。
AOFAOF 特點
以日志的形式來記錄用戶請求的寫操作。讀操作不會記錄，因為寫操作才會存存儲。
文件以追加的形式而不是修改的形式。
redis 的 aof 恢復其實就是把追加的文件從開始到結(jié)尾讀取執(zhí)行寫操作。
優(yōu)勢
AOF 更加耐用，可以以秒級別為單位備份，如果發(fā)生問題，也只會丟失最后一秒的數(shù)據(jù)，大大增加了可靠性和數(shù)據(jù)完整性。所以 AOF 可以每秒備份一次，使用 fsync 操作。
以 log 日志形式追加，如果磁盤滿了，會執(zhí)行 redis-check-aof 工具
當數(shù)據(jù)太大的時候，redis 可以在后臺自動重寫 aof。當 redis 繼續(xù)把日志追加到老的文件中去時，重寫也是非常安全的，不會影響客戶端的讀寫操作。
AOF 日志包含的所有寫操作，會更加便于 redis 的解析恢復。
劣勢
相同的數(shù)據(jù)，同一份數(shù)據(jù)，AOF 比 RDB 大
針對不同的同步機制，AOF 會比 RDB 慢，因為 AOF 每秒都會備份做寫操作，這樣相對與 RDB 來說就略低。每秒備份 fsync 沒毛病，但是如果客戶端的每次寫入就做一次備份 fsync 的話，那么 redis 的性能就會下降。
AOF 發(fā)生過 bug，就是數(shù)據(jù)恢復的時候數(shù)據(jù)不完整，這樣顯得 AOF 會比較脆弱，容易出現(xiàn) bug，因為 AOF 沒有 RDB 那么簡單，但是呢為了防止 bug 的產(chǎn)生，AOF 就不會根據(jù)舊的指令去重構(gòu)，而是根據(jù)當時緩存中存在的數(shù)據(jù)指令去做重構(gòu)，這樣就更加健壯和可靠了。
AOF 的配置
`# AOF 默認關閉，yes 可以開啟
appendonly no
# AOF 的文件名
appendfilename appendonly.aof
# no：不同步
# everysec：每秒備份，推薦使用
# always：每次操作都會備份，安全并且數(shù)據(jù)完整，但是慢性能差
appendfsync everysec
# 重寫的時候是否要同步，no 可以保證數(shù)據(jù)安全
no-appendfsync-on-rewrite no
# 重寫機制：避免文件越來越大，自動優(yōu)化壓縮指令，會 fork 一個新的進程去完成重寫動作，新進程里的內(nèi)存數(shù)據(jù)會被重寫，此時舊的 aof 文件不會被讀取使用，類似 rdb
# 當前 AOF 文件的大小是上次 AOF 大小的 100% 并且文件體積達到 64m，滿足兩者則觸發(fā)重寫
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb`到底采用 RDB 還是 AOF 呢？
如果你能接受一段時間的緩存丟失，那么可以使用 RDB
如果你對實時性的數(shù)據(jù)比較 care，那么就用 AOF
使用 RDB 和 AOF 結(jié)合一起做持久化，RDB 做冷備，可以在不同時期對不同版本做恢復，AOF 做熱備，保證數(shù)據(jù)僅僅只有 1 秒的損失。當 AOF 破損不可用了，那么再用 RDB 恢復，這樣就做到了兩者的相互結(jié)合，也就是說 Redis 恢復會先加載 AOF，如果 AOF 有問題會再加載 RDB，這樣就達到冷熱備份的目的了。
感謝各位的閱讀，以上就是“Redis 的持久化機制采用 RDB 還是 AOF”的內(nèi)容了，經(jīng)過本文的學習后，相信大家對 Redis 的持久化機制采用 RDB 還是 AOF 這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！
