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
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	丢数据	根据策略决定
轻重	重	轻