Redis 有两种持久化方案,RDB (Redis DataBase)和 AOF (Append Only File)
一:什么是AOF ?
AOF 全称是Append Only File,是 redis 记录执行指令的日志文件。
1. 工作原理
将写操作追加到文件中,AOF 日志是写后日志,“写后”的意思是 Redis 是先执行命令,把数据写入内存后,然后才记日志;里面记录的是指令执行的步骤,非常详细,描绘出了数据的变化过程。
2. AOF相关参数配置
参数配置在 redis.conf 文件里。
- appendonly no # 默认是no 表示不开启AOF机制,yes 代表开启
- appendfilename "appendonly.aof" # aof文件名,默认是"appendonly.aof"
- appendfsync everysec #aof持久化策略的配置,下文会详述
-
no-appendfsync-on-rewrite no # 是重写机制的相关参数,下文会说明
-
auto-aof-rewrite-percentage 100 # 是重写机制的相关参数,下文会说明
-
auto-aof-rewrite-min-size 64mb # 是重写机制的相关参数,下文会说明
- aof-use-rdb-preamble no # Redis从4.0开始就提出了一个混合使用 AOF 日志和内存快照的开关
3. AOF持久化策略
就是当数据被写入内存后,如何再写到文件的策略(为什么要写入文件,因为不持久化,redis挂了后,内存的数据没了,数据就丢了)
关于持久化同步时间节点上的控制有三个参数选项:
appendfsync always 表示不执行同步,由操作系统自己选择时间保证数据同步到磁盘,速度最快;
appendfsync everysec 表示每一秒执行一次同步,可能会导致丢失这1s数据
appendfsync no 表示每次写入内存后都执行同步,以保证数据同步到磁盘;
![](https://img2020.cnblogs.com/blog/1098960/202010/1098960-20201030112011550-524780402.png)
4. AOF的重写机制
很显然,因为AOF文件需要记录每一步的操作步骤,所以文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时,Redis就会对AOF文件的内容压缩。
重写的原理:Redis 会fork出一条新进程,读取当前内存中的数据,并重新写到一个临时文件中,这里没有读取旧文件(你都那么大了,我还去读你???),最后替换旧的aof文件。AOF 文件是以追加的方式,逐一记录接收到的写命令的。当一个键值对被多条写命令反复修改时,AOF 文件会记录相应的多条命令。但是在重写的时候,是根据这个键值对当前的最新状态,为它生成对应的写入命令。这样一来,一个键值对在重写的新日志中只用一条命令就行了,而且,在日志恢复时,只用执行这条命令,就可以直接完成这个键值对的写入了。所以新的AOF文件大小会大大缩小。
重写触发机制:当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。
- auto-aof-rewrite-percentage 100
默认值为100。aof自动重写配置,当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写,即当aof文件增长到一定大小的时候,Redis能够调用bgrewriteaof对日志文件进行重写,100代表大于一倍。
- auto-aof-rewrite-min-size 64mb
设置允许重写的最小aof文件大小,避免了达到约定百分比但尺寸仍然很小的情况还要重写,意思就是至少达到64mb,才重写
当redis宕机重启后,会读取 "appendonly.aof" 文件,将数据刷回到内存中去。
二:什么是RDB ?
这里解释为内存快照,就是指内存中的数据在某个时刻的状态记录。
1. 工作原理
RDB 是 Redis 默认的持久化方案。在指定的时间间隔内,执行指定次数的写操作,则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。与上述的aof相比,aof是持续的叠加写入,而RDB是整体写入,相当于给内存的数据拍下了一张张照片。
2. AOF相关参数配置
参数配置在 redis.conf 文件里。
- # save:这里是用来配置触发 Redis的持久化条件,也就是什么时候将内存中的数据保存到硬盘。默认如下配置
save 900 1 #表示900 秒内如果至少有 1 个 key 的值变化,则保存save 300 10 #表示300 秒内如果至少有 10 个 key 的值变化,则保存save 60 10000 #表示60 秒内如果至少有 10000 个 key 的值变化,则保存
-
# 默认值为yes。当启用了RDB且最后一次后台保存数据失败,Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上,否则没有人会注意到灾难(disaster)发生了。如果Redis重启了,那么又可以重新开始接收数据了stop-writes-on-bgsave-error yes
-
# 默认值是yes。对于存储到磁盘中的快照,可以设置是否进行压缩存储。如果是的话,redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话,可以设置为关闭此功能,但是存储在磁盘上的快照会比较大。rdbcompression yes
-
# 默认值是yes。在存储快照后,我们还可以让redis使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能。rdbchecksum yes
-
# 设置快照的文件名,默认是 dump.rdbdbfilename dump.rdb
-
# 设置快照文件的存放路径,这个配置项一定是个目录,而不能是文件名。使用上面的 dbfilename 作为保存的文件名。dir /usr/local/var/db/redis/
3. RDB的优缺点
优点:
适合大规模的数据恢复,如果业务对数据完整性和一致性要求不高,RDB是很好的选择。
缺点:
数据的完整性和一致性不高,因为RDB可能在最后一次备份时宕机了。
三:总结
- Redis 默认开启RDB持久化方式,在指定的时间间隔内,执行指定次数的写操作,则将内存中的数据写入到磁盘中。
- RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
- Redis 需要手动开启AOF持久化方式,默认是每秒将写操作日志追加到AOF文件中。
- AOF 的数据完整性比RDB高,但记录内容多了,会影响数据恢复的效率。
- Redis 针对 AOF文件大的问题,提供重写的瘦身机制。
- 若只打算用Redis 做缓存,可以关闭持久化。
- 若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份,留一后手。AOF出问题了,还有RDB。
优化建议:
1. 数据不能丢失时,内存快照和 AOF 的混合使用是一个很好的选择;
2. 如果允许分钟级别的数据丢失,可以只使用 RDB;
3. 如果只用 AOF,优先使用 everysec 的配置选项,因为它在可靠性和性能之间取了一个平衡。