Redis持久化AOF的特點有哪些

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

Redis 持久化 （AOF）

特點：

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

AOF保存的是appendonly.aof文件

配置：

appendonly no    ：默認關閉appendonly 模式 yes 開啟
appendfilename "appendonly.aof"      ：指定日志文件名稱

appendfsync ：

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

      everysec     出廠默認推薦，異步操作 ，每秒記錄  如果一秒內宕機，有數據丟失

      no            從不同步

no-appendfsync-on-rewrite no     ：重寫時是否可以運用 Appendfsync,默認no即可，保證數據安全性

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

實驗：查看日志文件

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

appendonly yes

2. 設置值

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文件內容

[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文件內容，模擬恢復文件過程

刪除 最后的 FLUSHALL ，保存

5. 啟動redis,查看數據

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.因為shutdown ，此時存在dum.rdb文件

8.此時啟動redis服務，出現問題

[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>

結論，aof 和rdb共存情況下，優先使用aof

9.修復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 查看修復結果

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 重寫機制

作用：AOF采用文件追加方式，文件會越來越大，為避免出現此種情況，新增了重寫機制，當AOF文件的大小超過所設定的閾值時，Redis就會啟動AOF文件的內容壓縮，只保留可以恢復數據的最小指令集。可以使用命令bgrewriteaof

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

觸發機制：Redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發。

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

13. 優勢

可設置 每秒同步、每修改同步、不同步

14. 劣勢

相同數據集的數據而言aof文件要遠大于rdb文件，恢復速度慢于rdb

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

15.AOF總結

16.Redis持久化總體總結

1. RDB持久化方式能夠在指定的時間間隔能對你的數據進行快照存儲

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

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

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

在這種情況下,當redis重啟的時候會優先載入AOF文件來恢復原始的數據,因為在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集要完整.

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

17. 性能建議

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

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