Redis的AOF持久化测试

AOF文件：

上面已经多次讲过，RDB的快照定时dump机制无法保证很好的数据持久性。如果我们的应用确实非常关注此点，我们可以考虑使用Redis中的AOF机制。对于Redis服务器而言，其缺省的机制是RDB，如果需要使用AOF，则需要修改配置文件中的以下条目：

将appendonly no改为appendonly yes

从现在起，Redis在每一次接收到数据修改的命令之后，都会将其追加到AOF文件中。在Redis下一次重新启动时，需要加载AOF文件中的信息来构建最新的数据到内存中。

redis.conf：（修改配置的配置文件）

APPEND ONLY MODE:

appendonly no --改为yes，redis启动时会加载AOF

appendfilename "appendonly.aof" --aof文件的名称，默认不变即可

#appendfsync always #每次有数据修改发生时都会写入AOF文件。

appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。

#appendfsync no #从不同步。高效但是数据不会被持久化。

no-appendfsync-on-rewrite no --在默认情况下，当aof进行重写时，aof的同步信息不是关闭的。在这种情况下，子进程rewrite（bgrewriteaof命令可进行aof文件异步重写）在写磁盘，在rewrite的过程中 子进程对主进程造成了磁盘阻塞（disk io冲突），导致了报警信息的产生。

--但是这个参数修改成 yes之后 ，又会有安全上的问题。因为这时候并没有执行磁盘操作，只是将命令写入了缓冲区。当rewrite的过程中 要是redis服务down掉的话 丢失的数据 就不是之前appendfsync 定下的策略。而是整个 rewrite 过程中的所有数据。

auto-aof-rewrite-percentage 100 --重启后，如果aof文件当前大小比重启时增长了百分之100就触发重写aof，做整合

auto-aof-rewrite-min-size 64mb --重启后，如果aof文件大小达到了64m就触发重写，做整合

aof-load-truncated yes --如果aof文件是被清空了的，重启时是否重载。有时候会有异常被清空，但是如果人家真的是想清空的，那也是得装载，所以默认为yes就好。

开始测试：

第一步：按照上面把配置文件redis.conf修改好，然后启动redis服务和客户端（分两个终端）

cd /usr/local/redis

./bin/redis-server redis.conf

cd/usr/local/redis

./bin/redis-cli

第二步：在客户端新建一个key，然后新开终端进/var/redis里面看是否产生了aof文件，产生了即AOF持久化生效

set strkey aa

可以看到命令已经存进来了。第一个命令是选择数据库，默认为数据库0。第二条命令就是set strkey aa，其中 *3 表示的是命令由三部分组成。

第三步：重启服务器，看key是否还存在

keys *

第四步：设置一个String类型的key，值为2，然后重复incr key命令，看aof文件内容。

命令如下：

set key1 1

incr key

incr key

..

..

aof内容如下：

可以发现，重复的命令会重复地写进aof文件里面，此时如果我们进行重写，结果会编程什么样呢？

第五步：在客户端执行 bgrewriteaof 命令，可进行后台进程重写aof。重写后看看aof文件内容。

可发现：最后省去所有命令，将key1的最后值赋给key1，即命令set key1 最后值

所以：上面的关于重写的命令auto-aof-rewrite-percentage，auto-aof-rewrite-min-size都是问了文件达到了一定的大小就进行重写， 就是对aof文件进行整合：将多余的命令都省去，直接改为赋值。