Redis持久化

前言

话不多说直奔主题…

RDB

主要触发机制

save

cli命令: save

文件策略： 如果存在老的RDB文件，新的将其替换掉

时间复杂度： O(n)

我们把客户端和服务端用一个图来表示，save时会帮我们生成一个RDB文件

由于它是同步命令，并且在单线程中执行,在数据量非常多的时候，此时执行save命令，他会将数据进行完整拷贝，可能会造成redis阻塞。

bgsave

通过在后台fork一个子进程完成复制

自动

根据REDIS配置定时同步数据到RDB文件

配置	Seconds	Changes
save	900	1
save	300	10
save	60	10000

eg:60秒中改变了10000次会发生备份RDB

触发机制-不容忽略的方式

• 全量复制
• Debug Reload
• shutdown

save or bgsave ?

命令	save	bgsave
IO类型	同步	异步
阻塞	是	发生在fork时
复杂度	O(N)	O(N)
优点	不会消耗内存	不阻塞客户端命令
缺点	阻塞客户端命令	消耗内存

### 配置

save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir ./
stop-writes-on-bgsave-error yes //bgsave出现问题会停止写入
rdbcompression yes  //压缩模式
rdbchecksum yes //对RDB进行校验和检验

#### 最佳配置

dbfilename dump-${port}.rdb
dir bigdiskpath //选择大的硬盘
stop-writes-on-bgsave-error yes //bgsave出现问题会停止写入
rdbcompression yes  //压缩模式
rdbchecksum yes //对RDB进行校验和检验

小结

• RDB是Redis内存到硬盘的快照，用于持久化
• save通常会阻塞Redis
• bgsave不会阻塞Redis，但是会fork子进程
• save自动配置满足其一就会被执行
• 有些触发机制不容忽视

RDB问题

耗时耗性能

O(N)数据耗时

fork耗内存

Disk I/O:IO性能

不可控丢失数据

时间戳	save
T1	执行多个命令
T2	满足RDB自动创建条件
T3	再次执行多条命令
T4	宕机

宕机会发生数据丢失

AOF

三种策略

everysec

always

同everysec流程，只不过always会把每条命令都写入到AOF文件中

no

由操作系统来决定是否刷新

比较

命令	always	everysec	no
优点	不丢失数据	每秒一次fsync丢1秒数据	不用管理
缺点	IO开销比较大	丢1秒数据	不可控

### AOF重写

作用

• 减少硬盘占用量
• 加快回复速度

重写两种方式

bgrewriteaof

命令：bgrewriteaof

重写配置

配置名	含义
auto-aof-rewirte-min-size	auto-aof-rewirte-percentage
AOF文件重写尺寸	AOF文件增长率

**统计**

统计名	含义
auto-current-size	auto-base-size
AOF当前尺寸	AOF上次启动和重写的尺寸

#### 自动触发时机

• auto-current-size > auto-aof-rewirte-min-size
• (auto-current-size - auto-base-size) / auto-base-size > auto-aof-rewirte-percentage

AOF重写流程

配置

• appendonly yes
• appendfilename “appendonly-${port}.aof”
• appendfsync everysec
• dir /bigdisk
• no-appendfsync-on-rewrite no //aof重写失败是否允许丢失数据
• auto-aof-rewrite-percentage 100 //增长率
• auto-aof-rewrite-min-size 64mb //最小尺寸

RDB 和 AOF 抉择

命令	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	丢数据	根据策略决定
轻重	重	轻