上篇文章说了RDB和AOF的工作原理,优缺点,适用背景,这次我们来测试一下。
一、把redis的持久化关闭。
1、RDB:
2、AOF:
3、删除 dump.rdb(有就删除,没有就算了) 文件与appendonly.aof(有就删除,没有就算了)
关闭持久化之后,启动redis服务端,连接客户端,设置一个key,关闭服务端,再次连接,观察该key是否存在?
启动redis服务端
连接客户端,设置一个key,关闭服务端
再次启动redis服务端
查看key
结果来看,关闭持久化,数据就得不到保存了,所以项目里持久化是要打开的。(如果只做缓存的话,可以不用开启持久化)
二、打开RDB,关闭AOF
1、打开RDB
重启redis服务器,继续 一 中的操作,如图:
重启redis服务器,连接redis,查看key
发现刚刚设的k2是存在的,那一切都是dump.rdb来帮我们完成的,我们去看一下这里面是什么东东,
cd /usr/local/src/redis-4.0.9/src,cat dump.rdb文件,
原理就是
当 Redis 需要保存 dump.rdb 文件时, 服务器执行以下操作:
- Redis 调用forks. 同时拥有父进程和子进程。
- 子进程将数据集写入到一个临时 RDB 文件中。
- 当子进程完成对新 RDB 文件的写入时,Redis 用新 RDB 文件替换原来的 RDB 文件,并删除旧的 RDB 文件。
二、关闭RDB,打开AOF
1、RDB
2、AOF
设置完之后,重复那一系列操作
重启redis服务端,连接客户端,查看key
除此之外,我还做了几个查询操作
那一切都是appendonly.aof来帮我们完成的,我们去看一下这里面是什么东东,
cd /usr/local/src/redis-4.0.9/src
cat appendonly.aof
select 0
mset k3 v3 k4 v3
由此可见,他会记录我们所有的写操作
原理
AOF 重写和 RDB 创建快照一样,都巧妙地利用了写时复制机制:
- Redis 执行 fork() ,现在同时拥有父进程和子进程。
- 子进程开始将新 AOF 文件的内容写入到临时文件。
- 对于所有新执行的写入命令,父进程一边将它们累积到一个内存缓存中,一边将这些改动追加到现有 AOF 文件的末尾,这样样即使在重写的中途发生停机,现有的 AOF 文件也还是安全的。
- 当子进程完成重写工作时,它给父进程发送一个信号,父进程在接收到信号之后,将内存缓存中的所有数据追加到新 AOF 文件的末尾。
- 现在 Redis 原子地用新文件替换旧文件,之后所有命令都会直接追加到新 AOF 文件的末尾。
如果这个时候我们来修改这个appendonly.aof,看看会是怎样
vim appendonly.aof,我们随便敲几个错误的命令进去,然后去启动redis,连接客户端
启动redis,连接客户端
我们可以看到客户端是连接不上的,因为appendonly.aof遭到了破坏(比如redis服务器突然断电或宕机)
这个时候我们可以用redis附带的redis-check-aof程序来修复
./redis-check-aof --fix appendonly.aof
可以看到 Successfully truncated AOF
那我们再来看一下appendonly.aof内容吧
发现一些错误的命令被修复清除了。
同理,redis-check-rdb 也有这种用法。
三、打开RDB,打开AOF
修改redis.conf,打开RDB持久化
重启,连接客户端,我们查看有哪些key(我们还记得 dump.rdb里有k2,appendonly.aof里k3,k4)
发现key里只有k3和k4,因为当RDB和AOF都打开的话,程序会优先使用 AOF 文件来恢复数据集, 因为 AOF 文件所保存的数据通常是最完整的。