Blog：博客園 個人
什么是持久化？簡單來講就是將資料放到斷電后資料不會丟失的設備中，也就是我們通常理解的硬碟上，
首先我們來看一下資料庫在進行寫操作時到底做了哪些事，主要有下面五個程序：
- 客戶端向服務端發送寫操作（資料在客戶端的記憶體中）;
- 資料庫服務端接收到寫請求的資料（資料在服務端的記憶體中）;
- 服務端呼叫write這個系統呼叫，將資料往磁盤上寫（資料在系統記憶體的緩沖區中）;
- 作業系統將緩沖區中的資料轉移到磁盤控制器上（資料在磁盤快取中）;
- 磁盤控制器將資料寫到磁盤的物理介質中（資料真正落到磁盤上）;
Redis持久化方式分為RDB和AOF，
RDB持久化
RDB(Redis DataBase)持久化是在指定的時間間隔內將記憶體中的資料集快照寫入磁盤，同時也是默認的持久化方式，
作業流程
配置
觸發方式
save m n # 表示m秒內資料集存在n次修改時，自動觸發bgsave
例如，以下可以同時配置：
# 900秒內執行1次更新
save 900 1
# 300秒內執行10次更新
save 300 10
# 60秒內執行10000次更新
save 60 10000
rdb檔案存放目錄
# 指定本地資料庫檔案名，一般采用默認的dump.rdb
dbfilename dump.rdb
# 備份檔案存放目錄，一般也用默認配置
dir ./
開啟資料壓縮
配置存盤至本地資料庫時是否壓縮資料，默認為yes，Redis采用LZF壓縮方式，但占用了一點CPU的時間，若關閉該選項，但會導致資料庫檔案變的巨大，建議開啟，
rdbcompression yes
AOF持久化
AOF(Append only file)持久化是以獨立日志的方式記錄每次命令，重啟時再重新執行AOF檔案中的命令達到恢復資料的目的，
AOF的主要作用是解決了資料持久化的實時性，
AOF直接采用文本協議格式(兼容性好)，開啟AOF后，所有寫入命令都包含追加操作，直接采用文本協議格式，避免了二次處理開銷，
作業流程
AOF的作業流程操作：命令寫入(append)、檔案同步(sync)、檔案重寫(rewrite)、重啟加載(load)，
流程如下：
- 所有的寫入命令會追加到aof_buf（緩沖區）中；
- AOF緩沖區根據對應的策略向硬碟做同步操作；
- 隨著AOF檔案越來越大， 需要定期對AOF檔案進行重寫， 達到壓縮的目的；
- 當Redis服務器重啟時， 可以加載AOF檔案進行資料恢復；
開啟AOF
默認不開啟，啟用AOF持久化方式
appendonly yes
# AOF檔案名稱
appendfilename "appendonly.aof"
# 備份檔案存放路徑，同RDB
dir ./
# 同步頻率
appendfsync everysec
appendfsync同步頻率配置參考：
- always：命令寫入
aof_buf后呼叫fsync操作同步到AOF檔案，fsync完成后執行緒回傳，每個 Redis 命令都要同步寫入硬碟，這樣會嚴重降低 Redis 的性能， - everysec：命令寫入
aof_buf后呼叫系統write操作，write完成后執行緒回傳，fsync同步檔案操作由專門執行緒每秒呼叫一次，每秒執行一次同步，顯式地將多個寫命令同步到硬碟， - no：命令寫入
aof_buf后呼叫系統write操作，不對AOF檔案做fsync同步，同步硬碟操作由作業系統負責，通常周期周長30秒，作業系統同步AOF檔案的周期不可控，會加大每次同步硬碟的資料量，資料安全性無法保證，
重寫機制
隨著命令不斷寫入AOF，檔案會越來越大，為了解決這個問題，Redis引入AOF重寫機制壓縮檔案體積，AOF檔案重寫是把Redis行程內的資料轉化為寫命令同步到新AOF檔案的程序，
重寫后的AOF檔案為什么可以變小？有如下原因：
- 行程內已經超時的資料不再寫入檔案，
- 舊的AOF檔案含有無效命令，如
del key1、hdel key2、srem keys、set a1111、set a222等，重寫使用行程內資料直接生成，這樣新的AOF檔案只保留最終的資料寫入命令， - 多條寫命令可以合并為一個，如：
lpuh list a、lpush list b、lpush list c可以轉化為：lpush list a b c，為了防止單條命令過大造成客戶端緩沖區溢位，對于list、set、hash、zset等型別操作，以64個元素為界拆分為多條，
AOF重寫不僅降低了檔案占用空間，而且更小的AOF檔案可以更快地被Redis加載，
觸發方式：
- 手動觸發：直接呼叫
bgrewriteaof命令； - 自動觸發：根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage引數確定自動觸發時機；
auto-aof-rewrite-min-size：表示運行AOF重寫時檔案最小體積，默認為64MB，
auto-aof-rewrite-percentage：代表當前AOF檔案空間(aof_current_size)和上一次重寫后AOF檔案空間(aof_base_size)的比值，
自動觸發時機=aof_current_size>auto-aof-rewrite-minsize&&（aof_current_size-aof_base_size） /aof_base_size>=auto-aof-rewritepercentage
流程說明：
- AOF持久化開啟且存在AOF檔案時， 優先加載AOF檔案， 列印如下
日志：
* DB loaded from append only file: 5.841 seconds
- AOF關倍訓者AOF檔案不存在時， 加載RDB檔案， 列印如下日志：
* DB loaded from disk: 5.586 seconds
- 加載AOF/RDB檔案成功后， Redis啟動成功，
- AOF/RDB檔案存在錯誤時， Redis啟動失敗并列印錯誤資訊，
RDB-AOF混合持久化
由于RDB持久化和AOF持久化都有各自的優缺點，因此在很長一段時間里，如何選擇合適的持久化方式成了很多Redis用戶面臨的一個難題，為了解決這個問題，Redis從4.0版本開始引入RDB-AOF混合持久化模式，這種模式是基于AOF持久化模式構建而來的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/263300.html
標籤：其他
上一篇：資料庫事務簡介.