Redis持久化方式RDB、AOF详解
之前已经写过一篇博客大概介绍了什么是RDB、AOF持久化,今天自己在本地搭建redis环境并实践了两种持久化方式。
持久化文件保存的路径在配置文件中的dir进行配置,默认为./ 当前路径下
1.RDB持久化
RDB快照方式(默认的持久化方式):通过设定指定时间段内的key值变化数量来触发redis的快照存储,一次性将内存中的所有数据保存在磁盘上(替换原来的rdb文件),配置文件可设置存储文件名称,RDB持久化方式的快照策略在配置文件中如下:
为了实现测试效果,修改快照策略为120秒内至少有两个键发生改变,在redis客户端执行两个写命令,120秒后查看日志执行了RDB存储
如日志打印所示,120秒发生了两个key的变化,redis fork一个1538的子进程完成RDB存储把数据保存在磁盘上,之后redis启动时会从磁盘中加载数据到内存。
RDB持久化方式的缺点:当Redis出现宕机后,将损失从最近一次快照到宕机时的数据
关闭持久化方式:注释掉save策略即可
2.AOF追加方式(将每一次的写命令记录到文件中,重启的时候从前到后执行这些命令)
配置文件中开启AOF持久化方式:appendonly yes;设置持久化文件名称:appendfilename appendonly.aof
写入策略:appendfsync 默认为每秒,每秒往aof文件中追加写入一次(该一秒内有写命令发生),如下,当客户端有写命令发生时,aof文件有更新
当redis长时间运行时,会有大量的写命令追加到文件,将导致aof文件过大,所以redis提供了一种重写机制
重写机制:简单来说,AOF文件重写是将内存的数据用一个写命令代替,举例说明,对key string进行赋值,第一次set string ‘1’,第二次 set string ‘2’,第三次 set string ‘3’, 这些命令都会被写入aof文件,当AOF文件重写时,内存中的string 值为 ‘3’,AOF就生成一条命令 set string ‘3’,并将此命令写入文件,这就是AOF文件的重写机制,可以有效缩小aof文件的大小
当然,实际的处理过程并没有这么简单,当AOF重写开始时,redis会fork出一个子进程,由子进程完成重写过程,子进程重写期间,主进程正常接收写命令并, 将写命令写入现有的AOF文件(旧的),重写开始时,子进程拥有了主进程的数据副本,将对这些数据进行重写,但是问题来了,子进程重写期间,主进程接收到的新的写命令怎么处理呢。子进程重写期间,主进程正常接收写命令并将写命令追加到现有的AOF文件和重写缓存中,重写缓存是在fork出子进程后启动的,重写完成后,重写缓存中的命令加入新的AOF文件,新的AOF文件替换旧的AOF文件,完成重写。
那redis重写机制是如何触发的呢,redis.conf中有如下配置
auto-aof-rewrite-percentage 100 :之后当前AOF文件的大小与上次重写时大小的比值达到100%时,触发重写
auto-aof-rewrite-min-size 100kb :当第一次AOF文件大小达到指定大小时,触发重写
为了达到测试效果,将两个配置的值都调小了,测试过程如下:
设置 auto-aof-rewrite-min-size=100kb,启动redis后,自动创建AOF文件,大小为0KB,当redis数据大小达到100kb时触发了重写,AOF文件大小变成4kb,继续增加数据到redis,当AOF文件大小达到100kb时,又触发了重写,100/100=1,两个重写配置是生效的
redis的持久化就介绍到这里,之后还会有很多redis的干货哦!