redis AOF持久化

概念

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

 

AOF默认不开启，需要手动在配置文件中配置

 

# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check http://redis.io/topics/persistence for more information.

appendonly no

 

可以在redis.conf中配置文件名称，默认为 appendonly.aof

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

 

 AOF文件的内容

AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

AOF和RDB同时开启，系统默认取AOF的数据

 

如果我写入了数据：

set k1 v1

可以看到这边有数据进去了。

ok, 如果你能看懂aof文件的内容，是否意味着你可以对它进行修改呢？

测试下，我修改了aof文件的内容：

 

 加了set k2 v2

然后我重启一下redis看看.

 

 

 我的测试结果是可以改。但是我以前听一个讲师说是不行。自己上面手动测试是可以修改，并且生效。

 

AOF文件故障恢复

如遇到AOF文件损坏，可通过 redis-check-aof --fix appendonly.aof 进行恢复。

 

AOF同步频率设置

# The default is "everysec", as that's usually the right compromise between
# speed and data safety. It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".

# appendfsync always
appendfsync everysec
# appendfsync no

always：始终同步，每次Redis的写入都会立刻记入日志（有时候写操作可能超级多，比较耗资源）
everysecond:每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
no:把不主动进行同步，把同步时机交给操作系统。

服务器运行性能：no > everysecond > always
但是数据的安全性来看：
always > everysecond > no


Rewrite

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof。

例如: 设置k1为0，然后incr 进行了4次，k1对应的值会是4

其实就相当于set k1 4

Redis如何实现重写

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

何时重写

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

AOF的优点

备份机制更稳健，丢失数据概率更低。

可读的日志文本，通过操作AOF稳健，可以处理误操作。

AOF的缺点

比起RDB占用更多的磁盘空间。

恢复备份速度要慢。

每次读写都同步的话，有一定的性能压力。

存在个别Bug，造成恢复不能。（aof在执行过程中也是有出bug的可能。）

RDB和AOF用哪个好

官方推荐两个都启用。

如果对数据不敏感，可以选单独用RDB。

不建议单独用 AOF，因为可能会出现Bug。

如果只是做纯内存缓存，可以都不用。