redis入门到精通系列（五）：redis的持久化操作（RDB、AOF）

2.1.2 bgsave操作

由于redis是单线程操作，而save指令的执行可能会阻塞当前Redis服务器，如果save指令执行时间长，后面的指令就都需要等待，所以线上环境不建议使用redis。取而代之的是bgsave指令.

bgsave   保存操作，但不是立即执行

当执行bgsave指令后，Redis会生成一个子进程去执行保存操作，Redis内部所有涉及RDB的操作都采用bgsave。

2.1.3 RDB设置

如果需要修改存放位置等信息，就需要进入到redis配置文件中修改，打开你的redis安装目录，选中下图配置文件

可以看到文件中有许多注解和参数，下面介绍几个：

dbfilename dump.rdb   文件名
dir ./                文件的保存路径,默认./
rdbcompression yes    存储至本地时是否压缩数据，默认开启
rdbchecksum yes       是否进行RDB文件格式校验，默认开启
save second changes   在second时间内发生了changes次变化就执行持久化 如：save 900 1,通常配置文件中会设置多个持久化规则

需要注意的是：Redis想要让配置文件中的信息生效，需要在启动服务时加上配置文件路径

2.1.4 RDB优缺点

首先是优点：

RDB是紧凑压缩的二进制文件，存储效率高。

RDB存储的是某个时间点内的数据快照，适用于数据备份，全量复制等场景。

RDB数据恢复速度快于AOF

缺点：

RDB无法做到实时持久化

bgsave运行时要启动一个子进程，牺牲了部分性能

RDB可能会出现不同版本服务器之间冲突的问题

（2.2） AOF

AOF以过程日志的方式保存每次的命令，保证了数据持久化的实时性

其中需要注意的是第三步，何时把数据从缓存放入硬盘是一个问题。AOF提供了三种策略

1.always（每次）：数据零误差，性能低

2.everysec（每秒）：准确性较高，性能较高

3.no（系统控制）：不可控

2.2.1 开启AOF

在配置文件中找到appendonly，默认是no，改为yes为开启

在配置文件中可以看到系统默认使用了everysec

可以看到在原本生成dump.rdb的同级目录下出现了appendonly.aof

这个文件记录了所有的操作。

2.2.2 AOF重写

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

AOF重写规则有以下几点：

进程内已超时的数据不再写入文件
忽略无效指令，重写时使用进程内数据直接生成
对同一数据的多条命令合并为一条命令，如lpush a a,lpush a b转化为lpush a a b

重写的方式

手动重写

bgrewriteaof

自动重写在配置文件中配置

//自动重写触发条件设置
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percent

第一条配置是让当前的size和设定的size作比较，当前size大于设定size就执行重写

第二条配置是按设定的百分比作比较，（当前的size-aof_base_size）/ aof_base_size的值大于百分比就执行重写

（2.3） AOF和RDB的区别

两者的区别通过一张表格的形式给到大家：

（三）持久化总结

redis的持久化如何用，用哪一种都需要根据实际情况具体分析。我们不可能让redis去取代mysql进行数据保存，但是在一些场景如断电保护等还是很有必要的。

redis入门到精通系列（五）：redis的持久化操作（RDB、AOF）

标签：epo   rewrite   div   release   docx   应该   class   写入   detail