Redis4.0之后可以使用RDB AOF混合方式进行持久化了,说到持久化,持久化在Redis里有两种使用场景
1 服务器重启的时候可以加载持久化文件恢复数据
2 AOF由于是采用顺序写的方式,所以经过一定的时间旧的AOF就不够新了需要进行重写保证数据一致性
现在看看怎么开启混合模式
# When rewriting the AOF file, Redis is able to use an RDB preamble in the
# AOF file for faster rewrites and recoveries. When this option is turned
# on the rewritten AOF file is composed of two different stanzas:
#
# [RDB file][AOF tail]
#
# When loading Redis recognizes that the AOF file starts with the "REDIS"
# string and loads the prefixed RDB file, and continues loading the AOF
# tail.
#
# This is currently turned off by default in order to avoid the surprise
# of a format change, but will at some point be used as the default.
aof-use-rdb-preamble no
把 aof-use-rdb-preamble 配成 yes就行了
上面的注释说了,开启了aof-use-rdb-preamble后,在对AOF进行重写的时候,AOF文件前半部分是RDB格式,后半部分是AOF格式
我们可以做个实验,下面是我在测试环境开启了aof-use-rdb-preamble后,手动执行下BGREWRITEAOF后生成的 appendonly.aof文件的内容
REDIS0008?redis-ver4.0.1?redis-bits繞?ctime聮~`?used-mem?? ?aof-preamble??repl-id(6c3378899b63bc4ebeaafaa09c27902d514eeb1f?repl-offset??? list1?77 / appleorangegrape?e k1v1彝髖S[zb*2
$6
SELECT
$1
0
*3
$4
sadd
$8
gamedisk
$4
nioh
*3
$4
sadd
$8
gamedisk
$4
tomb
前半部分是RDB格式,后半部分是AOF格式
关于AOF重写
顺便复习一下AOF重写吧
比如说一个客户端执行了五次下面的命令
RPUSH A
RPUSH B
RPUSH C
RPUSH D
RPUSH E
LRANGE
对于LIST,SET,HASH都是采用这种方式进行的压缩处理
伪代码如下
如果一个list或者set的成员数超过了64,重写的时候会分成多个语句,也就是说RPUSH 或者 SADD 中的成员不会超过64
三 AOF重写过程
1 fork出一个子进程,子进程调用上面伪代码的逻辑,生成新的AOF文件
2 在子进程生成aof文件期间,新的请求会缓存到AOF缓冲区,这是因为现在旧的AOF文件还是存在的,还是要每秒一次的频率写入的
3 除了AOF缓冲区,还有一个AOF重写缓冲区,客户端的操作也会保存到AOF重写缓冲区
当子进程完成AOF重写工作后,它会想父进程发送一个信号,父进程在收到信号之后,会调用一个信号处理函数,并执行以下工作
AOF重写缓冲区的所有内容写入到新的AOF文件中,这时新的AOF文件所保存的数据库状态和服务器当前的数据库状态一致
2 对新的AOF文件进行改名,原子地覆盖现有的AOF文件,完成文件替换
在主进程处理该信号期间,不会响应客户端请求