redis持久化

目录

持久化

快照

1.特点

2.快照生成方式

3.快照方式总结

AOF

1.特点

2.开启AOF持久化

3.日志追加频率

4.AOF文件的重写

4.1.AOF带来的问题        

4.2触发重写方式

4.3重写的原理

总结

---

持久化

Redis官方提供了两种持久化的方式，分别是：

• RDB快照(snapshot)：保存某一时刻redis中的所有数据状态，需要时恢复快照即可回到快照的状态
• AOF(Append Only File)追加日志文件：将所有redis的写命令记录到日志文件中，恢复时重新执行这些日志中的命令即可

快照

1.特点

这种方式可以将某一时刻的所有数据都写入硬盘中，当然这也是redis的默认开启持久化方式，保存的文件是以.rdb形式结尾的文件因此这种方式也称之为RDB方式。

2.快照生成方式

• 客户端方式：通过BGSAVE和SAVE命令
• 服务器配置自动触发，如下查看redis的安装目录可以看到系统自动生成的快照

BGSAVE和SAVE命令只需要在客户端下直接输入命令即可在redis目录中生成，比较简单。

1.BGSAVE和SAVE的区别：

• BGSAVE命令会调用fork系统调用来创建一个子进程，然后该子进程生成对应的快照并写入磁盘中，父进程不需要管，只需要完成自己的事情，继续处理命令请求。BG就是background后台执行的意思。

•  SAVE：当redis服务器接收到SAVE命令时，创建快照的操作是交给redis服务器自己去做的，创建快照期间是不会响应任何其他的命令的，就是前台执行，这种方式不建议使用，如果创建快照的操作比较慢，对客户端请求不友好。

2.服务器配置方式自动触发快照生成

用户在redis.conf中设置save配置选项，redis会在save选项满足条件之后自动触发一次BGSAVE命令(注意不是save命令)，可以设置多个save选项。如下

 还有一种情况就是客户端使用shutdown命令关闭redis服务器时，服务器会自动触发save命令创建一次快照，注意不是bgsave

另外也可以再配置文件中自定义快照的文件名和生成的目标目录，如下，其中的目录是基于redis-server脚本启动的目录。

3.快照方式总结

服务器每次开启时都回去加载那个生成的快照，如果把快照删除了再开启，那在redis服务器中就不会有任何数据了。

 缺点：

有丢失数据的风险，如果在客户端修改了数据后，服务器还没到时间更新快照，突然服务器宕机了，那么刚刚修改的数据就会丢失。

AOF

为了避免快照的数据丢失的风险，redis提供了AOF追加文件的方式，AOF持久化更能保护数据的完整性，但是丢失数据也是不可避免的，只能在最低限度保护数据。

1.特点

这种方式可以将所有客户端执行的写命令记录到日志文件中，AOF持久化会将被执行的写命令写到AOF的文件末尾，以此来记录数据发生的变化，因此只要redis从头到尾执行一次AOF文件所包含的所有写命令，就可以恢复AOF文件的记录的数据集。

2.开启AOF持久化

在redis的默认配置中AOF持久化机制是没有开启的，需要在配置文件中开启。

3.日志追加频率

当我们开启AOF功能后，并不是输入一个更新数据的命令就立即把该命令同步到appendonly.aof文件中，redis中默认的是每一秒钟同步一次命令到文件。

redis也提供了三种追加频率：

• always：每个redis写命令都同步写入到磁盘，这种方式可以将数据丢失的风险降低到最小，但是验证影响效率，需要谨慎使用
• everysec：每一秒钟同步一次，将多个写命令写入到磁盘中，可以保证用户最多丢失一秒之内产生的数据
• no：由操作系统决定何时同步，不推荐

如下可以修改该配置

AOF和RDB持久性可以同时启用，不会出现问题。如果同时启动，Redis将加载AOF，即文件具有更好的耐久性保证。

4.AOF文件的重写

4.1.AOF带来的问题        

AOF相比快照方式更安全，最多丢失1秒的数据，但是AOF也有一个问题，就是持久化文件会变的越来越大。如我们调用incr 命令100次，AOF文件则保存了全部的100条，其实99条都是多余的。为了压缩AOF的持久化文件Redis提供了AOF重写机制。用来在一定程度上减小AOF文件的体积。

4.2触发重写方式

• 在客户端模式下，执行BGREWRITEAOF命令，不会阻塞redis的服务
• 服务器配置方式自动触发，如下可以设置percentage 的值控制自动触发的时机

4.3重写的原理

注意：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，替换原有的文件这点和快照有点类似。

1. redis调用fork ，现在有父子两个进程，子进程根据内存中的数据库快照，往一个临时文件中写入重建数据库状态的命令
2. 父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
3. 当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
4. 现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。
    

总结

两种持久化方案既可以同时使用(aof)，又可以单独使用，在某种情况下也可以都不使用，具体使用那种持久化方案取决于用户的数据和应用决定。

无论使用AOF还是快照机制持久化，将数据持久化到硬盘都是有必要的，除了持久化外，用户还应该对持久化的文件进行备份(最好备份在多个不同地方)。