09_Redis持久化——AOF方式

【AOF简述】

AOF（Append-only）

Redis每次接受到一条改变数据的命令时，它会把该命令写到一个AOF文件中（只记录写操作，不记录读操作），当Redis启动时，它通过执行AOF文件中的所有命令来恢复数据。

【AOF】

当使用Redis存储非临时数据时，一般需要打开AOF持久化来降低进程终止导致的数据丢失。

AOF可以将Redis执行的每一条写命令追加到硬盘文件中，这一过程显然会降低Redis的性能，但是大部分情况下这个影响是可以接收的，另外使用较快的硬盘可以提高AOF的性能。

【配置AOF】

【开启AOF】

默认情况下Redis是咩有开启AOF（append only file）方式的持久化，可以通过appendonly参数启动：

appendonly yes

开启AOF持久化后每执行一条写命令，Redis就会将该命令写入硬盘中的AOF文件。

AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改。

【总结】

【总结——aof优点】

1.比RDB可靠。你可以制定不同的fsync策略：不进行fsync、每秒fsync一次和每次查询进行fsync。
默认是每秒fsync一次。这意味着你最多丢失一秒钟的数据。
2.AOF日志文件是一个纯追加的文件。就算是遇到突然停电的情况，也不会出现日志的定位或者损坏问题。
甚至如果因为某些原因（例如磁盘满了）命令只写了一半到日志文件里，我们也可以用redis-check-aof这个工具很简单的进行修复。
3.当AOF文件太大时，Redis会自动在后台进行重写。重写很安全，
因为重写是在一个新的文件上进行，同时Redis会继续往旧的文件追加数据。新文件上会写入能重建当前数据集的最小操作命令的集合。
当新文件重写完，Redis会把新旧文件进行切换，然后开始把数据写到新文件上。
4.AOF把操作命令以简单易懂的格式一条接一条的保存在文件里，很容易导出来用于恢复数据。
例如我们不小心用FLUSHALL命令把所有数据刷掉了，只要文件没有被重写，我们可以把服务停掉，把最后那条命令删掉，
然后重启服务，这样就能把被刷掉的数据恢复回来。

【总结——aof缺点】

1.在相同的数据集下，AOF文件的大小一般会比RDB文件大。
2.在某些fsync策略下，AOF的速度会比RDB慢。通常fsync设置为每秒一次就能获得比较高的性能，
而在禁止fsync的情况下速度可以达到RDB的水平。
3.在过去曾经发现一些很罕见的BUG导致使用AOF重建的数据跟原数据不一致的问题。