6. Redis AOF
6.1 簡介
目前，redis的持久化主要應用AOF（Append Only File）和RDF兩大機制，AOF以日志的形式來記錄每個寫操作（增量保存），將redis執(zhí)行過的所有指令全部安全記錄下來（讀操作不記錄）。只許追加文件，但不可以改寫文件，redis啟動之初，會讀取該文件，重新構建數(shù)據(jù)。
6.2 AOF的配置
- AOF默認不開啟,在conf配置文件中進行配置。
- 修改redis.conf配置文件
appendonly no //修改 appendonly yes - 默認文件名是appendonly.aof
- 默認是啟動后的相對路徑，redis在哪里啟動，appendonly.aof文件就在哪生成
6.3 AOF日志是如何實現(xiàn)
數(shù)據(jù)庫寫前日志(Write Ahead Log ,WAL)，在實際寫數(shù)據(jù)庫前，先把修改的數(shù)據(jù)記錄到日志文件中，以便發(fā)生故障時，時行恢復。
AOF日志是寫后日志。redis先去執(zhí)行命令，把數(shù)據(jù)寫入內(nèi)存中，然后才去記錄日志。
查看AOF文件
set k1 v1
vi appendonly.aof
*3 //接下來的指令由3部分組成
$3 //指令有3個字節(jié)
set
$2 //指令有2個字節(jié)
k1
$2 //指令有2個字節(jié)
v1
為什么使用寫后日志？
- redis為了避免檢查開銷，向AOF中記錄日志，是不做檢查的。如果寫前執(zhí)行，很有可能將錯誤指令記錄到日志中，在使用redis恢復日志時，就可能會出現(xiàn)錯誤
- 不會阻塞當前的寫操作
6.4 AOF 的潛在風險
- aof文件可能由于異常原因被損壞?？梢允褂胷edis自帶的命令redis-check-aof --fix appendonly.aof文
件，修復成功，可以正確啟動 - 由于剛剛執(zhí)行一個指令，還沒有寫入日志，就宕機了。就會導致數(shù)據(jù)永久丟失(redis做為數(shù)據(jù)庫存儲的
情況) - AOF避免了對當前指令的阻塞，但可能會由于磁盤寫入壓力較大，對下一個操作帶來阻塞風險
6.5 AOF三種寫回策略
打開redis.conf配置文件 appendfsync選項
- always：同步寫回:每個寫指令執(zhí)行完，立即同步將指令寫入磁盤日志文件中
- everysec：每秒寫回：默認配置方式。每個寫指令執(zhí)行完，先把日志寫到AOF文件的內(nèi)存緩沖區(qū)。每隔一秒把緩沖區(qū)的內(nèi)容寫入磁盤
- no：操作系統(tǒng)控制寫回：每個寫指令執(zhí)行完，先把日志寫到AOF文件的內(nèi)存緩沖區(qū)，由操作系統(tǒng)決定何時把緩沖區(qū)的內(nèi)容寫入磁盤
| 選項 | 寫日志時機 | 優(yōu)點 | 缺點 |
|---|---|---|---|
| always | 同步寫回 | 數(shù)據(jù)可靠性高，基本不丟失 | 對性能影響大 |
| everysec | 每秒寫回 | 性能適中 | 當服務器宕機時，丟失1秒內(nèi)數(shù)據(jù) |
| no | 操作系統(tǒng)控制寫回 | 性能最高 | 當服務器宕機時，丟失數(shù)據(jù)較多 |
6.6 AOF重寫機制
6.6.1 簡介
Redis根據(jù)數(shù)據(jù)庫現(xiàn)有數(shù)據(jù)，創(chuàng)建一個新的AOF文件，讀取數(shù)據(jù)庫中所有鍵值對，重新對應一條命令寫入。
可以使用命令bgrewriteaof
重寫主要是對多余的命令進行簡化，修改，例如對list的lpush和rpop進行簡化
6.6.2 AOF重寫的相關配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
如果aof文件超過64m，且比上次重寫后的大小增加了100%，自動觸發(fā)重寫。
例如 文件80m，開如重寫，重寫后降到50m，下一次，達到100m再開始重寫。
6.6.3 AOF重寫流程
- bgrewirteaof觸發(fā)重寫，判斷是否當前有重寫在運行，如果有，則等待重寫結束后再執(zhí)行
- 主進程fork出一個子進程，執(zhí)行重寫操作，保證主進程不阻塞，可以繼續(xù)執(zhí)行命令
- 子進程循環(huán)遍歷reids內(nèi)存中的所有數(shù)據(jù)到臨時文件，客戶端的寫請求同時寫入aof緩沖區(qū)和aof重寫緩沖區(qū)。保證原AOF文件完整以及新的AOF文件生成期間的新的數(shù)據(jù)修改操作不會丟失
- 子進程寫完新AOF文件以后，向主進程發(fā)送信號，主進程更新統(tǒng)計信息
- 主進程把aof重寫緩沖區(qū)中的數(shù)據(jù)寫入到新的AOF文件
- 用新AOF文件覆蓋掉舊的AOF文件，完成AOF重寫
7. Redis RDB
7.1 簡介
RDB（Redis DataBase）：內(nèi)存快照，記錄內(nèi)存中某一時刻數(shù)據(jù)的狀態(tài)。
RDB和AOF相比記錄的數(shù)據(jù)，不是操作指令
redis提供了兩個指令生成RDB文件
- save：再主線程中執(zhí)行，會阻塞主線程
- bgsave：創(chuàng)建一個子線程，專門用來寫RDB，避免主線程阻塞，默認配置
例如：有6GB的內(nèi)存數(shù)據(jù)量，磁盤寫入0.3GB/S，需要20S時間，來完成RDB文件寫入，其中在這20中可能會有寫入或修改數(shù)據(jù)
- 處理技術：寫時復刻技術（copy-on-write cow）。在執(zhí)行快照處理的時候，依然正確執(zhí)行寫入操作（快照將修改數(shù)據(jù)創(chuàng)建副本，保存的時修改之前的數(shù)據(jù)）
7.2 快照頻率
通過redis.conf配置文件去做處理
# save 3600 1
# save 300 100
# save 60 10000
7.3 混合使用AOF和RDB
通過redis.conf配置文件
打開aof
appendonly yes
打開混合配置文章來源：http://www.zghlxwxcb.cn/news/detail-642121.html
aof-use-rdb-preamble yes
在aof文件中，前半部分，就是rdb文件的內(nèi)容，從rewirte之后，是aof文件內(nèi)容
文章來源地址http://www.zghlxwxcb.cn/news/detail-642121.html
7.4關于對redis執(zhí)久化處理的建議
- 如果數(shù)據(jù)在服務器運行的時候，使用redis做緩沖，可以不使用任何持久化方式
- 數(shù)據(jù)不能丟失，rdb和aof混合使用是一個好的選擇
- 如果數(shù)據(jù)不要求非常嚴格，要以允許分鐘級別丟失，可以使用rdb
- 如果只使用AOF，建議配置策略是everysec，在可靠性和性能之間做了一個折中
- 如果磁盤允許，盡量避免AOF重寫的頻率,將默認值64M進行修改
到了這里，關于Redis_持久化（AOF、RDB）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
