Redis中RDB與AOF的區(qū)別及說明
1.概述
在Redis的使用中，持久化是一個重要的特性，它將內(nèi)存中的數(shù)據(jù)保存到硬盤上，以防止數(shù)據(jù)丟失。
Redis 提供了三種主要的持久化方式：AOF（Append Only File）、RDB（Redis DataBase）以及混合持久化（RDB和AOF）。
本文將詳細介紹 AOF 和 RDB 的區(qū)別及配置方式，幫助讀者更好地理解和選擇合適的持久化方式。
2.RDB和AOF
2.1 RDB
2.1.1 RDB概念
RDB 持久化方式是 Redis 將當前內(nèi)存中的數(shù)據(jù)快照（snapshot）保存到硬盤的過程。
這種方式是就是將內(nèi)存中數(shù)據(jù)以快照的方式寫入到二進制文件中，默認的文件名為dump.rdb。其實就是每隔一段時間，Redis 會創(chuàng)建一個代表某一時刻的數(shù)據(jù)集的磁盤文件。
2.1.2 RDB工作原理（Copy-On-Write）
RDB 的生成過程依賴于操作系統(tǒng)的寫時復制（COW）機制，這一機制確保了快照生成期間 Redis 依然能正常處理讀寫請求，不會阻塞業(yè)務。
具體流程如下：
- 1.觸發(fā)快照生成：當滿足預設條件時（時間到、達到修改次數(shù)閾值），Redis 主進程會fork 一個子進程（此時子進程與主進程共享同一塊內(nèi)存空間）；
- 2.子進程寫入快照：子進程負責遍歷內(nèi)存中的所有數(shù)據(jù)，將其序列化后寫入一個臨時的.rdb 文件；
- 3.主進程正常服務：在子進程生成快照期間，主進程繼續(xù)處理客戶端的讀寫請求。若有數(shù)據(jù)被修改，操作系統(tǒng)會為該數(shù)據(jù)塊創(chuàng)建一個副本，主進程修改副本數(shù)據(jù)，而子進程依然讀取原始數(shù)據(jù)（避免快照被污染）；
- 4.替換舊快照：當子進程完成快照寫入后，會用臨時文件替換當前的.rdb 文件，至此一次 RDB 持久化完成。
2.1.3 RDB觸發(fā)方式
1.自動觸發(fā)：基于配置的"指定時間+修改次數(shù)"
在Redis 的配置文件（redis.conf）中，通過save指令定義RDB的觸發(fā)規(guī)則，格式為：
save <seconds> <changes> [<seconds> <changes> ...]
表示 “在 seconds 秒內(nèi)，若數(shù)據(jù)修改次數(shù)達到 changes 次，則觸發(fā) RDB”。
默認配置如下：
# 3600秒(1小時)內(nèi)修改1次、300秒內(nèi)修改100次、60秒內(nèi)修改10000次，滿足任一條件即觸發(fā)RDB save 3600 1 save 300 100 save 60 10000
2.手動觸發(fā)：主動備份場景
手動觸發(fā)主要通過save、bgsave指令實現(xiàn)：
- save命令：由主進程直接生成 RDB，期間會阻塞所有客戶端請求（線上不推薦使用，會阻塞請求導致業(yè)務中斷）；
- bgsave命令：主進程 fork 子進程生成 RDB，主進程本身不阻塞（線上手動觸發(fā)的首選指令）
3.RDB核心配置文件
#指定 RDB 文件的名稱，默認為dump.rdb dbfilename dump.rdb #指定 RDB 文件的保存路徑，默認是 Redis 的啟動目錄（建議改為絕對路徑，如/var/redis/） dir ./ #是否對 RDB 文件進行壓縮（默認開啟，用 CPU 開銷換取磁盤空間，關閉可提升快照速度） rdbcompression yes #是否對 RDB 文件進行校驗（默認開啟，通過 CRC64 算法確保文件完整性，關閉可提升加載速度） rdbchecksum yes
4.RDB優(yōu)缺點
優(yōu)點：
- 恢復速度快： RDB 是二進制的全量快照，加載時無需解析復雜指令，僅需反序列化數(shù)據(jù)，適合大規(guī)模數(shù)據(jù)的快速恢復；
- 文件體積?。?/strong> 壓縮后的 RDB文件體積遠小于 AOF 文件，便于備份和傳輸；
- 對性能影響?。?/strong> 子進程負責生成快照，主線程僅在fork子進程時短暫阻塞（阻塞時間與內(nèi)存大小相關，通常毫秒級），對業(yè)務讀寫影響低。
缺點：
- 數(shù)據(jù)一致性低： RDB獲取的是“某一時間點快照”，若在兩次快照間隔期間 Redis 宕機，則該時間段內(nèi)修改的數(shù)據(jù)將全部丟失（例如：配置save 30 1000，則最多可能丟失30秒的數(shù)據(jù)）；
- 文件可讀性性低： RDB 文件是一個二進制文件，并不是一個易于讀取和理解的文本文件；
- 不適合實時備份： 存在丟失數(shù)據(jù)的可能，適用于對數(shù)據(jù)一致性要求不高的業(yè)務。
2.2 AOF
2.2.1 AOF概念
AOF其實就是將每一個收到的寫命令都通過write函數(shù)追加到文件中，當 Redis 需要恢復數(shù)據(jù)時，只需執(zhí)行 AOF 文件中的命令就可以恢復到原來的狀態(tài)。
這個文件有點像MySQL的binlog日志文件，只不過binlog日志文件是二進制，Redis的AOF生成的文件是文本格式。
2.2.2 AOF工作原理
1.命令追加
- 每當 Redis 執(zhí)行一條寫命令并成功處理后，會將該命令按照 Redis 協(xié)議格式追加到內(nèi)存中的 “AOF 緩沖區(qū)”（避免直接寫入磁盤，降低IO開銷）。
- 2.文件刷盤AOF 緩沖區(qū)中的命令需要定期寫入磁盤，刷盤策略由appendfsync配置決定。
3.日志重寫
- 隨著運行時間延長，AOF 文件會產(chǎn)生大量重復命令（如多次set同一個key）而變得異常龐大，占用大量磁盤空間，還會導致Redis重啟恢復時間邊長。
- Redis攜帶了 “日志重寫” 機制，會生成一個包含 “當前內(nèi)存數(shù)據(jù)最終狀態(tài)” 的精簡 AOF 文件，替換舊的AOF文件，能有效降低空間占用率、提升恢復效率。
例如：
- 若指定key的值經(jīng)過多次set，最終是value3，AOF文件中記錄了SET key value1、SET key
- value2、SET key value3三條命令，重寫后只會保留SET key value3一條命令。
2.2.3 AOF配置
1.啟用AOF
# 啟用AOF（默認no） appendonly yes # AOF文件名稱，默認appendonly.aof appendfilename "appendonly.aof" # AOF文件保存路徑，與RDB一致 dir ./
2.刷盤策略
appendfsync定義了 AOF 緩沖區(qū)的命令何時寫入磁盤，有三種可選值：
| 值 | 解釋 |
|---|---|
| always | 每執(zhí)行一條寫命令，立即將緩沖區(qū)內(nèi)容寫入到磁盤，數(shù)據(jù)安全性高，IO頻繁 |
| everysec | 每秒將緩沖區(qū)內(nèi)容寫入磁盤一次，數(shù)據(jù)安全性一般，性能適中 |
| no | 由操作系統(tǒng)決定何時寫入磁盤，默認30秒刷盤一次，數(shù)據(jù)安全性低，性能較高 |
3.日志重寫規(guī)則
AOF 重寫同樣支持自動觸發(fā)和手動觸發(fā)，自動觸發(fā)通過auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置實現(xiàn)：
auto-aof-rewrite-percentage 100 # 當AOF文件大小比上次重寫后增大100%（即翻倍）時觸發(fā) auto-aof-rewrite-min-size 64mb # 當AOF文件大小至少達到64MB時才觸發(fā)（避免小文件頻繁重寫）
手動觸發(fā)：執(zhí)行bgrewriteaof命令，主進程 fork 子進程完成重寫，不阻塞業(yè)務（和bgsave類似）。
4.AOF優(yōu)缺點
優(yōu)點：
- 數(shù)據(jù)一致性高： 可通過appendfsync always實現(xiàn) “數(shù)據(jù)零丟失”，或everysec實現(xiàn) “最多丟失 1 秒數(shù)據(jù)”，滿足高一致性需求；
- 日志可讀性強： 由于AOF 文件是一個易于讀取和理解的文本文件，可以方便地進行數(shù)據(jù)恢復、備份和分析；
- 可靠性高： 記錄了Redis執(zhí)行的所有寫操作，可以提供更可靠的數(shù)據(jù)持久性，避免數(shù)據(jù)丟失。
缺點：
- 恢復速度慢： 恢復數(shù)據(jù)時需要執(zhí)行大量的寫命令，因此恢復速度相對較慢；
- 文件體積大： 即使經(jīng)過重寫，AOF 文件體積通常仍大于 RDB 文件，占用更多磁盤空間；
- 性能開銷較高： 每次寫操作都需要追加到 AOF 文件中，可能會導致磁盤 I/O 的負載增加。
2.3 RDB與AOF對比
| RDB | AOF | |
|---|---|---|
| 優(yōu)點 | 文件體積小，恢復速度相對較快，對系統(tǒng)性能影響較小 | 可讀性高，數(shù)據(jù)安全性高，支持實時恢復 |
| 缺點 | 數(shù)據(jù)安全性相對較低，可讀性低，無法滿足大規(guī)模、對數(shù)據(jù)備份要求高的場景 | 文件體積較大，恢復速度相對較慢，對系統(tǒng)性能有一定影響 |
| 適用場景 | 對數(shù)據(jù)安全性要求相對較低，希望快速地進行數(shù)據(jù)恢復 | 對數(shù)據(jù)安全性要求較高，而且可以接受稍慢一些的恢復速度 |
3.總結
1.RDB持久化方式能夠在指定的時間間隔內(nèi)對數(shù)據(jù)進行快照存儲；
2.AOF持久化方式記錄每次對服務器寫的操作，服務器重啟時會重新執(zhí)行這些命令來恢復原始的數(shù)據(jù)；
3.RDB和AOF可同時開啟，Redis重啟時會優(yōu)先載入AOF文件來恢復原始數(shù)據(jù)，因為通常情況下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整；
4.一般情況下，RDB文件只用作后備用途，建議只在slave機器上持久化RDB文件，并且只要15分鐘備份一次就夠了；
5.如果只做緩存，只希望數(shù)據(jù)在服務器運行的時候存在，其實不需要持久化操作。
以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。
相關文章
這篇文章主要介紹了Redis Cluster集群主從切換的踩坑與填坑，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧2021-04-04
哨兵模式,是基于主從復制模式,主從復制的優(yōu)點全都擁有,并且主從可以實現(xiàn)自動切換,故障轉移等功能,本文主要介紹了Windows下搭建Redis哨兵集群模式的方法步驟,文中通過圖文介紹的非常詳細,感興趣的小伙伴們可以參考一下,需要的朋友可以參考下2023-09-09
Springboot/Springcloud項目集成redis進行存取的過程解析
大家都知道Redis支持五種數(shù)據(jù)類型：string（字符串），hash（哈希），list（列表），set（集合），zset(sorted set：有序集合)，本文重點給大家介紹Springboot/Springcloud項目集成redis進行存取的過程，需要的朋友參考下吧2021-12-12
Redis 是一個開源、高性能的Key-Value數(shù)據(jù)庫，被廣泛應用在服務器各種場景中。本文介紹幾個查看Redis內(nèi)存信息的命令，包括常用的info memory、info keyspace、bigkeys等。2020-09-09
這篇文章主要給大家介紹了關于Redis如何分析慢查詢操作的相關資料，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2018-09-09
這篇文章主要為大家介紹了Redis?Lua同步鎖實現(xiàn)源碼解析，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪2023-05-05
RedisYML配置是Redis的一種配置文件格式,,對Redis的配置進行統(tǒng)一管理,本文就來介紹了redis yml配置的用法小結,具有一定的參考價值,感興趣的可以了解一下2024-02-02
這篇文章主要介紹了Redis序列化存儲及其日期格式的問題處理方式，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2021-12-12
通過prometheus監(jiān)控redis實時運行狀態(tài)的操作方法
本文詳細介紹了如何通過Prometheus監(jiān)控Redis的運行狀態(tài),包括安裝配置Redis、Redis Exporter以及Prometheus,配置Prometheus監(jiān)控Redis指標,以及常見的Redis指標和告警規(guī)則,需要的朋友可以參考下2025-02-02
RabbitMQ+redis+Redisson分布式鎖+seata實現(xiàn)訂單服務的流程分析
訂單服務涉及許多方面,分布式事務,分布式鎖,例如訂單超時未支付要取消訂單,訂單如何防止重復提交,如何防止超賣、這里都會使用到,這篇文章主要介紹了RabbitMQ+redis+Redisson分布式鎖+seata實現(xiàn)訂單服務的流程分析,需要的朋友可以參考下2024-07-07