上篇文章说了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 文件所保存的数据通常是最完整的。