一文帶你了解Redis持久化完整版本

本文講解知識點

持久化的簡介

RDB

AOF

RDB與AOF的區別

持久化應用場景

對于持久化這個功能點，其實很簡單沒有那么復雜

Redis持久化

演示環境

1. 持久化簡介

2. RDB

2-1 RDB啟動方式 -- save命令

2-2 RDB啟動方式 -- save指令相關配置

2-3 RDB數據恢復

2-4 RDB -- save指令工作原理

2-5 RDB -- bgsave指令工作原理

2-5 RDB -- 配置文件自啟動

3. AOF

3-1 AOF概念

3-2 AOF寫數據過程

3-3 AOF寫數據的三種策略

3-4 AOF功能開啟

3-5 AOF寫數據出現的問題

3-6 AOF重寫

3-7 AOF重寫作用

3-8 AOF重寫規則

3-9 AOF手動重寫

3-10 AOF手動重寫工作原理

3-11 AOF自動重寫

3-11 AOF工作流程和重寫流=流程

4. RDB和AOF區別

演示環境

centos7.0

redis4.0

redis存放目錄：/usr/local/redis

redis.conf存放目錄：/usr/local/redis/data

1. 持久化簡介

redis的所有數據都是保存在內存中，redis崩掉數據會丟失。redis持久化就是把數據保存在磁盤上。利用永久性存儲介質將數據進程保存，在特定的時間將保存的數據進行恢復的工作機制稱為持久化。

持久化過程保存的是什么呢？

第一種快照形式，存儲數據結果，關注點在數據，也就是下文會講到的RDB

第二種操作過程，存儲操作過程，存儲結構復雜，關注點在數據的操作過程，也就是下文會講到的AOF

2. RDB

2-1 RDB啟動方式 – save命令

下圖是redis.conf的配置信息，在執行完save后會生成一個dump.rdb的文件

現在我們設置一個值，然后save一下，在/usr/local/redis/data下就會有一個dump6379.rdb的一個文件

2-2 RDB啟動方式 – save指令相關配置

dbfilename dump6379.rdb ：設置本地數據庫文件名，默認值為dump.rdb

dir：存儲rdb文件的路徑

rdbcompression yes ：設置存儲至本地數據庫時是否壓縮數據，默認為yes，采用lzf壓縮

rdbchecksum yes：設置是否進程RDB文件格式校驗，該校驗過程在寫文件和讀文件過程均進行

2-3 RDB數據恢復

其實這個數據恢復相對于其他關系型數據庫恢復基本就不用操作什么。只需要重新在啟動就好了

2-4 RDB – save指令工作原理

此圖來源于網絡視頻。

save指令的執行會阻塞當前redis服務器，直到當前RDB過程完為止，有可能會造成長時間的阻塞。這個指令在工作過程中基本以被廢棄不在使用。會以bgsave全部代替

2-5 RDB – bgsave指令工作原理

當在redis執行了bgsave后會直接返回一個Background saving started

這個時候我們在看一下日志文件，bgsave命令是針對save阻塞問題做的優化

2-5 RDB – 配置文件自啟動

save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes

1

2

3

4

save 【時間】 【key改變數量】

也就是說在300秒有10個key值發生變化了，就會在后臺執行bgsave

3. AOF

3-1 AOF概念

AOF持久化：以獨立日志的方式記錄每次寫命令，重啟時在重新執行AOF文件中命令達到數據恢復的目的。與RDB相比可以簡單描述為記錄數據產生的過程

AOF的主要作用是解決了數據持久化的實時性，目前已經是redis持久化的主流方式

3-2 AOF寫數據過程

執行一條redis命令

redis的AOF會把命令刷新緩沖區

然后根據一定的策略同步的到redis.conf配置的.aof文件中

3-3 AOF寫數據的三種策略

always：每次寫入操作均同步到AOF文件中，數據零誤差，性能較低，不建議使用

everysec：每秒將緩沖區中的指令同步到AOF文件中，數據準確性較高，性能較高，建議使用，也是默認配置。但是在系統突然宕機的情況下回丟失1秒內的數據

no：由操作系統控制每次同步到AOF文件的周期，整體過程不可控

3-4 AOF功能開啟

配置：appendonly yes|no

作用：是否開啟AOF持久化功能，默認為不開啟狀態

配置：appendfsync always| everysec | no

作用：AOF寫數據策略

配置：appenfilename filename

作用：AOF持久化文件名，默認名為appendonly.aof

然后使用重啟redis服務，就可以在usr/local/redis/data目錄下可以看到appendonly.aof文件了

然后我們在redis客戶端執行一條命令，在來查看一下。可以看到數據都會存入appendonly.aof這個文件中。

3-5 AOF寫數據出現的問題

我們先看一個案例，我們重復設置了name這個key后，打開appendonly.aof文件查看，可以看到有三個操作，但是這三個操作我們都是修改的一個key啊！我們只保存最后一個key不行嗎？帶著這個疑問，我們在繼續往下看

3-6 AOF重寫

隨著命令不斷寫入AOF，文件會越來越大，為了解決這個問題，redis引入了AOF重寫機制壓縮文件體積。AOF文件重寫是將redis進程內的數據轉化為寫命令同步到新AOF文件的過程。簡單說就是將對同一個數據的若干條命令執行結果轉化為最終結果數據對應指令的執行記錄。

如在上邊我們執行了三次 set name 指令，但是我們最終就只需要最后一次執行的數據。也就是我們只需要最后一次執行記錄即可。

3-7 AOF重寫作用

降低磁盤占用量，提高磁盤利用率

提高持久化效率，降低持久化寫時間，提高IO性能

降低數據恢復用時，提高數據恢復效率

3-8 AOF重寫規則

進程內已超時的數據不再寫入文件

忽略無效指令，重寫時使用進程內數據直接生成，這樣新的AOF文件值保留最終數據的寫入命令。如del指令，hdel，srem。 多次設置一個key值等

對同一數據的多條寫入命令合并為一條命令：如lpush list a lpush lsit b lpush list c可以轉化為lpush list a b c。但是為了防止數據量過大造成客戶端緩沖區溢出，對list，set，hash，zset類型每條指令最多寫入64個元素

3-9 AOF手動重寫

指令：bgrewriteaof

接著我們3-5的問題，我們在命令行執行bgrewriteaof指令然后查看appendonly.aof文件

當執行完后會發現文件變小了，文件里也就只有一條指令了

3-10 AOF手動重寫工作原理

3-11 AOF自動重寫

配置：auto-aof-rewrite-percentage 100 | auto-aof-rewrite-min-size 64mb

觸發對比參數：aof_current_size | aof_base_size

當aof_current_size > auto-aof-rewrite-min-size 64mb 會啟動重寫

此圖來源于網絡

3-11 AOF工作流程和重寫流=流程

4. RDB和AOF區別

對數據非常敏感，建議使用默認的AOF持久化方案

AOF持久化策略使用everysecond, 每 秒 鐘fsync-次?該策略redis仍可以保持很好的處理性能，當出現問題時， 最 多丟失0-1秒內的數據.

注意：由于AO文件存儲體積較大，且恢復速度較慢

數據呈現階段有效性，建議使用RDB持久化方案

數據可以良好的做到階段內無丟失（該階段是開發者成運維人手工維護的），且恢復速度較快，階段點數據恢復通常采用RDB方案

注 意 ： 利 用RDB實現緊促的數據持久化會使Redis降的很低

綜合對比

RDB與AOF的選擇實際上是在做一種權衡，每種都有利有弊

如不能承受數分鐘以內的數據丟失，對業努數據非常敏感，選用A0F

如能承受數分鐘以內的數據丟失，旦追求大數據集的恢復速度，選用RDB

災難恢復使用RDB

雙保險策略，同時幵啟RDB和AOF, 重啟后，Redis優先使用A0F來恢復數據，降低丟失數據的量

Redis 任務調度

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。