Redis持久化AOF的特點(diǎn)有哪些

這篇文章主要介紹了Redis持久化AOF的特點(diǎn)有哪些，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

Redis 持久化 （AOF）

特點(diǎn)：

以日志的形式來記錄每個寫操作，將Redis執(zhí)行過的所有寫指令記錄下來（讀操作不記錄），只許追加文件但不可以改寫文件，redis啟動之初會讀取該文件重新構(gòu)建數(shù)據(jù)，換言之，redis重啟的話根據(jù)日志文件的內(nèi)容將寫指令從前到后執(zhí)行一次已完成數(shù)據(jù)的恢復(fù)工作。

AOF保存的是appendonly.aof文件

配置：

appendonly no    ：默認(rèn)關(guān)閉appendonly 模式 yes 開啟
appendfilename "appendonly.aof"      ：指定日志文件名稱

appendfsync ：

      always        每次修改同步持久化  每次發(fā)生數(shù)據(jù)變更會被立即記錄到磁盤  性能較差但數(shù)據(jù)完整性比較好

      everysec     出廠默認(rèn)推薦，異步操作 ，每秒記錄  如果一秒內(nèi)宕機(jī)，有數(shù)據(jù)丟失

      no            從不同步

no-appendfsync-on-rewrite no     ：重寫時是否可以運(yùn)用 Appendfsync,默認(rèn)no即可，保證數(shù)據(jù)安全性

auto-aof-rewrite-percentage 100  :設(shè)置重寫的基準(zhǔn)
auto-aof-rewrite-min-size 64mb   ：設(shè)置重寫的最小文件大小
    AOF文件大小是上次rewrite后大小的一倍 且文件大于64M時觸發(fā)重寫

實(shí)驗(yàn)：查看日志文件

1.修改配置文件，開啟AOF

appendonly yes

2. 設(shè)置值

127.0.0.1:9736> set k1 v1
OK
127.0.0.1:9736> set k2 v2
OK
127.0.0.1:9736> set k3 v3
OK
127.0.0.1:9736> set k4 v4
OK
127.0.0.1:9736> FLUSHALL
OK
127.0.0.1:9736> shutdown
not connected> exit
[root@VM_0_7_centos bin]#

3.查看aof文件內(nèi)容

[root@VM_0_7_centos bin]# cat appendonly.aof 
*2
$6
SELECT
$1
0
*3
$3
set
$2
k1
$2
v1
*3
$3
set
$2
k2
$2
v2
*3
$3
set
$2
k3
$2
v3
*3
$3
set
$2
k4
$2
v4
*1
$8
FLUSHALL
[root@VM_0_7_centos bin]#

4. 編輯 aof文件內(nèi)容，模擬恢復(fù)文件過程

刪除 最后的 FLUSHALL ，保存

5. 啟動redis,查看數(shù)據(jù)

127.0.0.1:9736> keys *
1) "k2"
2) "k3"
3) "k1"
4) "k4"

6. 編輯aof文件，模擬斷電，aof文件損壞

在最后加入亂碼，

set
$2
k4
$2
v4
123123123
-- INSERT --

7.因?yàn)閟hutdown ，此時存在dum.rdb文件

8.此時啟動redis服務(wù)，出現(xiàn)問題

[root@VM_0_7_centos bin]# redis-server /myredis/redis_aof.conf 
18695:C 23 Sep 2020 15:18:43.773 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
18695:C 23 Sep 2020 15:18:43.774 # Redis version=6.0.5, bits=64, commit=00000000, modified=0, pid=18695, just started
18695:C 23 Sep 2020 15:18:43.774 # Configuration loaded
[root@VM_0_7_centos bin]# redis-cli -p 9736
Could not connect to Redis at 127.0.0.1:9736: Connection refused
not connected>

結(jié)論，aof 和rdb共存情況下，優(yōu)先使用aof

9.修復(fù)aof  redis-check-aof --fix  appendonly.aof

[root@VM_0_7_centos bin]# redis-check-aof --fix  appendonly.aof
0x              8b: Expected prefix '*', got: '1'
AOF analyzed: size=150, ok_up_to=139, diff=11
This will shrink the AOF from 150 bytes, with 11 bytes, to 139 bytes
Continue? [y/N]: y
Successfully truncated AOF

10.啟動redis 查看修復(fù)結(jié)果

127.0.0.1:9736> keys *
1) "k4"
2) "k2"
3) "k3"
4) "k1"

11.配置文件中說明

# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.

12. Rewite 重寫機(jī)制

作用：AOF采用文件追加方式，文件會越來越大，為避免出現(xiàn)此種情況，新增了重寫機(jī)制，當(dāng)AOF文件的大小超過所設(shè)定的閾值時，Redis就會啟動AOF文件的內(nèi)容壓縮，只保留可以恢復(fù)數(shù)據(jù)的最小指令集?？梢允褂妹頱grewriteaof

原理：AOF文件持續(xù)增長而過大時，會fork出一條新進(jìn)程來將文件重寫（也是先寫臨時文件最后在rename），遍歷新進(jìn)程的內(nèi)存中數(shù)據(jù)，每條記錄有一條的Set語句。重寫aof文件的操作，并沒有讀取舊的aof文件，而是將整個內(nèi)存中的數(shù)據(jù)庫內(nèi)容用命令的方式重寫了一個新的aof文件，這點(diǎn)和快照有點(diǎn)類似。

觸發(fā)機(jī)制：Redis會記錄上次重寫時的AOF大小，默認(rèn)配置是當(dāng)AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發(fā)。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

13. 優(yōu)勢

可設(shè)置 每秒同步、每修改同步、不同步

14. 劣勢

相同數(shù)據(jù)集的數(shù)據(jù)而言aof文件要遠(yuǎn)大于rdb文件，恢復(fù)速度慢于rdb

AOF運(yùn)行效率要慢于rdb，每秒同步策略效率較好，不同步效率和rdb相同。

15.AOF總結(jié)

16.Redis持久化總體總結(jié)

1. RDB持久化方式能夠在指定的時間間隔能對你的數(shù)據(jù)進(jìn)行快照存儲

2. AOF持久化方式記錄每次對服務(wù)器寫的操作,當(dāng)服務(wù)器重啟的時候會重新執(zhí)行這些命令來恢復(fù)原始的數(shù)據(jù),AOF命令以redis協(xié)議追加保存每次寫的操作到文件末尾.Redis還能對AOF文件進(jìn)行后臺重寫,使得AOF文件的體積不至于過大

3. 只做緩存：如果你只希望你的數(shù)據(jù)在服務(wù)器運(yùn)行的時候存在,你也可以不使用任何持久化方式.

4. 同時開啟兩種持久化方式,

在這種情況下,當(dāng)redis重啟的時候會優(yōu)先載入AOF文件來恢復(fù)原始的數(shù)據(jù),因?yàn)樵谕ǔＧ闆r下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整.

RDB的數(shù)據(jù)不實(shí)時，同時使用兩者時服務(wù)器重啟也只會找AOF文件。那要不要只使用AOF呢？作者建議不要，因?yàn)镽DB更適合用于備份數(shù)據(jù)庫(AOF在不斷變化不好備份)，快速重啟，而且不會有AOF可能潛在的bug，留著作為一個萬一的手段。

17. 性能建議

因?yàn)镽DB文件只用作后備用途，建議只在Slave上持久化RDB文件，而且只要15分鐘備份一次就夠了，只保留save 900 1這條規(guī)則。
如果Enalbe AOF，好處是在最惡劣情況下也只會丟失不超過兩秒數(shù)據(jù)，啟動腳本較簡單只load自己的AOF文件就可以了。代價一是帶來了持續(xù)的IO，二是AOF rewrite的最后將rewrite過程中產(chǎn)生的新數(shù)據(jù)寫到新文件造成的阻塞幾乎是不可避免的。只要硬盤許可，應(yīng)該盡量減少AOF rewrite的頻率，AOF重寫的基礎(chǔ)大小默認(rèn)值64M太小了，可以設(shè)到5G以上。默認(rèn)超過原大小100%大小時重寫可以改到適當(dāng)?shù)臄?shù)值。
如果不Enable AOF ，僅靠Master-Slave Replication 實(shí)現(xiàn)高可用性也可以。能省掉一大筆IO也減少了rewrite時帶來的系統(tǒng)波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的數(shù)據(jù)，啟動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個。新浪微博就選用了這種架構(gòu)

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“Redis持久化AOF的特點(diǎn)有哪些”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關(guān)注億速云行業(yè)資訊頻道，更多相關(guān)知識等著你來學(xué)習(xí)!