Redis是一款高性能的key-value型数据库，在项目中使用也非常广泛，每一个开发人员都应该掌握这项技能。在今天的这篇文章中我们详细的介绍下Redis持久化相关的内容。

我们都知道Redis是基于内存的，读写数据都是操作的内存，但数据并不会因为我们重启服务而消失，这是通过Redis的持久化保证的。

在Redis中提供了RDB和AOF两种持久化方式，这两种方式可以单独使用，也可以同时使用，在一些情况下也可以都不使用。

一、RDB

RDB持久化方式是通过生成内存快照的方式将某一时刻的状态以文件的形式保存到磁盘上，这个快照文件被称作RDB文件。

当我们重启服务后直接读取这个文件进行数据恢复即可，这种持久化方式可以很快的进行数据恢复，但当服务发生宕机时，将丢失最近一次创建快照文件之后写入的所有数据，数据安全性较差。

以下情况Redis服务会生成快照文件

• 客户端执行save或者bgsave命令;
• 使用shutdown命令关闭服务时会先执行下save的逻辑;
• 满足redis配置文件中save配置项设置的条件时;

1、save和bgsave命令

save命令是通过主线程创建快照文件，在处理完成之前主线程无法再处理其他客户端请求，因此这个命令要慎用。

bgsave命令是通过fork的子线程来创建快照文件，主线程可以继续处理其他客户端的请求。

2、save配置项

RDB文件的生成规则还可以使用save配置项进行配置，在redis7.0版本的配置项说明如下：

配置格式为 save <seconds> <changes> [<seconds> <changes> ...]
save 3600 1 300 100 60 10000

上面的配置意义为

• 3600秒后有一条变更就生成快照
• 300秒后有100条变更就生成快照
• 60秒后有10000条变更就生成快照

这个配置需要根据业务系统允许丢失数据的多少进行配置。

3、rdb相关配置项

• save 生成RDB文件的条件
• stop-writes-on-bgsave-error
• rdbcompression 执行RDB快照时是否将string类型的数据进行压缩
• rdbchecksum 是否开启RDB文件内容的校验
• dbfilename 文件名称 默认为dump.rdb
• rdb-del-sync-files
• dir 文件存放路径
• rdb-save-incremental-fsync

二、AOF

RDB持久化方式可能会丢失最近一次创建快照文件之后写入的所有数据，如果我们对系统的安全性要求较高，可以使用AOF这种持久化。

AOF持久化是通过追加命令的方式实现的，Redis执行完收到的写命令后，将这条命令以文本的形式记录到AOF文件中。需要恢复数据时，从头到尾执行下AOF文件中包含的所有命令即可。在Redis中这种持久化方式默认是关闭的，可以通过appendonly配置项开启。

以set key value为例，AOF日志格式如下图所示：

1、写回策略

磁盘操作是一个比较耗时的操作，如果每次执行完一条命令就更新磁盘肯定会影响Redis的性能，在Redis首先是将日志写入aof_buf缓冲区，然后根据appendfsync的配置使用具体的写回策略，在Redis中提供了三种写回策略，如下：

• always 同步写回：执行完一个写命令立马将日志写会磁盘。可靠性高，数据基本不丢失；性能影响较大。
• everysec 每秒写回：每隔一秒把缓冲区中的内容写入磁盘。性能适中，宕机时最多丢失1s内的数据。
• no 操作系统控制写回：由操作系统决定何时将缓冲区内容写回磁盘。性能好，宕机时丢失的数据较多。

具体选择哪种写回策略需要根据我们系统对性能和可靠性的要求进行决定，想要尽可能的获得高性能，就选择no；想要尽可能的获得可靠性，就选择always；允许数据有一点的丢失，同时又希望性能别受太大影响，就选择everysec。

2、AOF重写

随着时间的推移，AOF文件会越来越大，对该文件的读写性能都会变差。为了解决这个问题，Redis中提供了AOF重写机制。

进行Redis重写是根据Redis数据库当前的状态重新生成一个AOF文件，也就是读取库所有的键值对，然后为每一个键值对生成一条命令进行记录。为何这样会使文件变小呢？举一个简单的例子大家就清楚了，例如我对一个key调用了10次set操作，在原来的AOF文件中会记录着10个命令，而进行重写后的文件中只会记录最后一条set日志。

什么时候会进行AOF重写呢，相关条件是在Redis配置文件中指定的，内容如下:

# 文件大小的增长率
auto-aof-rewrite-percentage 100
# 文件的最小大小
auto-aof-rewrite-min-size 64mb

3、混合持久化

RDB和AOF有各自的优点和缺点，有没有什么方式兼顾RDB文件快速恢复数据和AOF数据可靠性的方式呢？在Redis4.0版本中提供了混合持久化的功能。

混合持久化是指在进行AOF文件重写时，将Redis数据库当前状态以RDB的格式写入AOF文件中，在Redis重启时会按照RDB和AOF两种解析方式进行数据恢复。

混合持久化功能需要使用如下配置项进行开启：

aof‐use‐rdb‐preamble yes

4、AOF相关配置项

• appendonly 是否开启AOF功能 默认为no
• appendfilename AOF文件名称 默认为appendonly.aof
• appendfsync 写回磁盘的策略 默认为everysec
• no-appendfsync-on-rewrite 默认为no

• auto-aof-rewrite-percentage AOF重写时需要满足的文件大小增长率 默认为100
• auto-aof-rewrite-min-size AOF重写时需要满足文件的最小大小默认为64MB
• aof-load-truncated 在执行RDB生成或者AOF重写时是否进行写回磁盘 默认为no
• aof-use-rdb-preamble 是否开启混合持久化 默认yes

三、总结

在今天的文章中介绍了下Redis中的持久化方式，都是些理论性的东西，无需死记硬背。希望大家能够了解一下几点

• Redis提供了哪些持久化方式;
• RDB和AOF两种持久化的区别及各自的优缺点;
• AOF日志的写回策略、重写及混合持久化;

欢迎大家关注我的公众号：【Bug搬运小能手】