redis的持久化

redis持久化

做用：redis 的全部數據保存在內存中，redis持久化就是能夠把內存中保存的數據放進磁盤中。

方式：

方式	相似
RDB	快照
AOF	寫日誌，把新的記錄添加到末尾

RDB

原理

其實RDB的原理就是相似於建立快照。

實現的方式

• save命令

save

save命令是同步的，對於特別大的數據和訪問量大的網站都會發生阻塞

• bgsave命令

bgsave

bgsave命令是異步的，因此不會形成命令阻塞，可是由於該命令會額外的建立一個進程的子進程，因此會產生必定量的開銷

• 自動生成，就是達到某個條件時，ROF文件就會自動生成，在配置文件下能夠看到如下幾個配置

save 900 1
save 300 10
save 60 10000

例如：在900秒內有一次改變就發生save命令

建議的配置

dbfilename #二進制文件（快照）的名字
dir#二進制文件存放的位置
stop-write-on-bgsave-error#bgsave失敗，是否中止寫入
rdbcompression#是否使用壓縮格式
rdbchecksum#對二進制文件進行校驗

文件策略：存在老的RDB文件，新的就會替換老的

缺點：耗時，耗性能，不可控，丟失數據

AOF

原理

相似於咱們寫日誌，把操做的每一條命令行都記錄到日誌文件中

三種策略（其實就是配置的三種選項）

• always （會把每一條命令都實時得寫入到aof文件中）
• everysec（默認，會把每一秒執行的命令記錄到aof文件中）
• no（根據系統來決定什麼時候記錄到aof文件中）

命令	always	everysec	no
優勢	不丟失數據	每一秒執行一個同步	不用管
缺點	IO開銷大	有可能丟失一秒的數據	不可控

AOF的重寫

原理：

由於在咱們實際的使用中，有不少的命令是重複的，多餘的或者是過時的，例如set hello word， set hello Peter，實際上只有後句命令纔有效，而重寫就是隻記錄了後面的那一句話。

重寫的做用

• 減小磁盤佔用量
• 加速恢復速度

重寫的兩種實現的方法

• bgrewriteaof

相似於RDB中的bgsave命令

• AOF重寫配置

其實也是在內部調用bgrewriteof

配置名	含義
auto_aof_rewrite_min_size	AOF文件重寫須要的尺寸
auto_aof_rewrite_percentage	AOF文件增加率

AOF的統計

統計名	含義
aof_current_size	AOF當前的尺寸（單位：字節）
aof_base_size	AOF上次啓動和重寫的尺寸（單位：字節）

經過配置啓動重寫的條件

• aof_current_size > auto_aof_rewrite_min_size
• (aof_current_size - aof_base_size) / aof_base_size > auto_aof_rewrite_percentage

AOF的流程

注意：3-1：當AOF文件重寫的過程當中，新的數據也會寫入到平常的AOF文件中。5-2則是在AOF文件重寫的時間段期間有新的命令傳進來也會被重寫進當前正在重寫的AOF文件中。（語文水平有限，哈哈，但願能理解）

AOF的相關配置

appendonly yes #使用AOF必定要開啓配置
appendfilename "appendonly-${port}.aof" #AOF文件的名稱
appendfsync everysec #AOF文件的策略
dir / #存放的地址
no_appendfsync_on_rewrite yes #這個配置就是說明在AOF重寫的過程當中不進行平常的AOF文件寫入
auto_aof_rewrite_percentage 100
auto_aof_rewrite_min_size 64mb

AOF和RDB的抉擇

命令	RDB	AOF
啓動優先級	低	高
體積	小	大
恢復速度	快	慢
數據安全性	丟數據	根據策略決定
輕重	重	輕