Redis的持久化機制采用RDB還是AOF

這篇文章主要講解了“Redis的持久化機制采用RDB還是AOF”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Redis的持久化機制采用RDB還是AOF”吧！

RDB

1. 什么是RDB

RDB：每隔一段時間，把內存中的數據寫入磁盤的臨時文件，作為快照，恢復的時候把快照文件讀進內存。如果宕機重啟，那么內存里的數據肯定會沒有的，那么再次啟動redis后，則會恢復。

2. 備份與恢復

內存備份 --> 磁盤臨時文件
臨時文件 --> 恢復到內存

3. RDB優劣勢

• 優勢

• 每隔一段時間備份，全量備份

• 災備簡單，可以遠程傳輸

• 子進程備份的時候，主進程不會有任何io操作（不會有寫入修改或刪除），保證備份數據的的完整性

• 相對AOF來說，當有更大文件的時候可以快速重啟恢復

• 劣勢

• 發生故障是，有可能會丟失最后一次的備份數據

• 子進程所占用的內存比會和父進程一模一樣，如會造成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：可能造成數據不一致

• rdbcompression

• yes：開啟rdb壓縮模式

• no：關閉，會節約cpu損耗，但是文件會大，道理同nginx

• rdbchecksum

• yes：使用CRC64算法校驗對rdb進行數據校驗，有10%性能損耗

• no：不校驗

總結

RDB適合大量數據的恢復，但是數據的完整性和一致性可能會不足。

AOF

AOF特點

• 以日志的形式來記錄用戶請求的寫操作。讀操作不會記錄，因為寫操作才會存存儲。

• 文件以追加的形式而不是修改的形式。

• redis的aof恢復其實就是把追加的文件從開始到結尾讀取執行寫操作。

優勢

• AOF更加耐用，可以以秒級別為單位備份，如果發生問題，也只會丟失最后一秒的數據，大大增加了可靠性和數據完整性。所以AOF可以每秒備份一次，使用fsync操作。

• 以log日志形式追加，如果磁盤滿了，會執行 redis-check-aof 工具

• 當數據太大的時候，redis可以在后臺自動重寫aof。當redis繼續把日志追加到老的文件中去時，重寫也是非常安全的，不會影響客戶端的讀寫操作。

• AOF 日志包含的所有寫操作，會更加便于redis的解析恢復。

劣勢

• 相同的數據，同一份數據，AOF比RDB大

• 針對不同的同步機制，AOF會比RDB慢，因為AOF每秒都會備份做寫操作，這樣相對與RDB來說就略低。 每秒備份fsync沒毛病，但是如果客戶端的每次寫入就做一次備份fsync的話，那么redis的性能就會下降。

• AOF發生過bug，就是數據恢復的時候數據不完整，這樣顯得AOF會比較脆弱，容易出現bug，因為AOF沒有RDB那么簡單，但是呢為了防止bug的產生，AOF就不會根據舊的指令去重構，而是根據當時緩存中存在的數據指令去做重構，這樣就更加健壯和可靠了。

AOF的配置

`# AOF 默認關閉，yes可以開啟
appendonly no

# AOF 的文件名
appendfilename "appendonly.aof"

# no：不同步
# everysec：每秒備份，推薦使用
# always：每次操作都會備份，安全并且數據完整，但是慢性能差
appendfsync everysec

# 重寫的時候是否要同步，no可以保證數據安全
no-appendfsync-on-rewrite no

# 重寫機制：避免文件越來越大，自動優化壓縮指令，會fork一個新的進程去完成重寫動作，新進程里的內存數據會被重寫，此時舊的aof文件不會被讀取使用，類似rdb
# 當前AOF文件的大小是上次AOF大小的100% 并且文件體積達到64m，滿足兩者則觸發重寫
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb`

到底采用RDB還是AOF呢？

• 如果你能接受一段時間的緩存丟失，那么可以使用RDB

• 如果你對實時性的數據比較care，那么就用AOF

• 使用RDB和AOF結合一起做持久化，RDB做冷備，可以在不同時期對不同版本做恢復，AOF做熱備，保證數據僅僅只有1秒的損失。當AOF破損不可用了，那么再用RDB恢復，這樣就做到了兩者的相互結合，也就是說Redis恢復會先加載AOF，如果AOF有問題會再加載RDB，這樣就達到冷熱備份的目的了。

感謝各位的閱讀，以上就是“Redis的持久化機制采用RDB還是AOF”的內容了，經過本文的學習后，相信大家對Redis的持久化機制采用RDB還是AOF這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！