Redis的持久化AOF模式,以日志的形式记录服务器所处理的每一个写操作,在Redis服务启动之初会读取该文件来重新构建数据库,以保证启动后数据库中的数据是完整的。
AOF的优点:
1、可以带来更高的数据安全性。
2、由于对日志文件的写入操作采用的是append模式,因此在写入过程汇总即使出现宕机,也不会破坏日志文件中已经存在的内容,然而如果我们本次操作写入一半数据就出现系统崩溃,可以在Redis下一次启动之前,通过redis-check-aof工具帮助解决数据一致性的问题。
3、如果日志过大,Redis可以启动rewrite机制,即Redis以append模式不断的将修改数据写入到老的磁盘文件中,同时Redis还会创建一个新的文件用于记录此期间有哪些修改指令被执行,rewrite切换时可以更好的保证数据安全性。
4、AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作,可以通过该文件完成数据的重建。
AOF的缺点:
1、相同的数据的数据集,AOF文件通常要大于RDB文件。
2、同步策略的不同,AOF在运行效率上往往会慢于RDB,每秒同步策略的效率是比较高的,同步禁用策略的效率和RDB一样高效。
在Redis的配置文件中存在三种同步方式,它们分别是:
1、appendfsync always:每次有数据修改发生时都会写入AOF文件。
2、appendfsync everysec:每秒钟同步一次,该策略为AOF的缺省策略。
3、appendfsyn no:从不同步,高效的那是数据不会被持久化。
如何修复损坏的AOF文件?
1、将现有已经损坏的AOF文件额外复制出来一份。
2、执行‘redis-check-aof -- fix <filename>‘命令来修复损坏的AOF文件。
3、用修复后的AOF文件重新启动Redis服务。
redis.conf的配置,将appendonly改为yes
Redis一启动就会在dir目录下生成appendonly.aof,开始这个文件是0字节的。
查看key,有多少
dump.rdb文件时33字节,为什么之前设置的key,没有了呢?
原因:一旦appendonly设置为yes,系统会优先读appendonly.aof文件,而不是dump.rdb
由于appendonly.aof是空的,所以看到key也是空的。
设置一些key
appendonly.aof就变成了112字节
查看appendonly.aof文件,其实是将上面设置的命令记录了一下。
AOF的启动装载
1、AOF优先于RDB
2、RDB的性能优于AOF,因为没有重复
3、Redis一次性将数据加载到内存中,一次性预热
Redis的装载源码如下:
AOF的rewrite
AOF的rewrite参数
原文地址:http://blog.csdn.net/lhl6688/article/details/43636719