redis持久化之AOF

Append-only File（AOF）Redis每次接收到一条改变数据的命令时，它将把该命令写到一个AOF文件中（只记录写操作，不记录读操作），当Redis重启时，它通过执行AOF文件中所有的命令来恢复数据。
AOF是在RDB之后出现的一种技术，这种方式的持久化让redis的数据不会丢失；
当使用Redis存储非临时数据时，一般需要开启AOF持久化来降低Redis故障导致的数据丢失，AOF可以将Redis执行的每一条写命令追加到硬盘文件中，这一过程会降低Redis的性能，但大部分情况下这个影响是能够接受的，另外使用较快的硬盘（固态硬盘）可以提高AOF的性能；

AOF方式的数据持久化，仅需在redis.conf文件中配置即可，搜索APPEND ONLY MODE；
配置文件 appendonly no 默认是no，改成yes即开启aof持久化；

2.AOF的相关配置选项

appendonly
默认是no，改成yes即开启了aof持久化；
appendfilename
指定AOF文件名，默认文件名为appendonly.aof；（该文件要Redis自己启动创建，测试发现我们自己创建该文件，无法向文件写入持久化命令）
appendfsync
配置向aof文件写命令数据的策略：
no：不主动进行同步操作，而是完全交由操作系统来做（即每30秒一次），比较快但不是很安全;
always：每次执行写入都会执行同步，慢一些但是比较安全
everysec：每秒执行一次同步操作，比较平衡，介于速度和安全之间
dir
指定AOF和RDB文件的目录
auto-aof-rewrite-percentage
当目前aof文件大小超过上一次重写时的aof文件大小的百分之多少时会再次进行重写，如果之前没有重写，则以启动时的aof文件大小为依据
auto-aof-rewrite-min-size
允许重写的最小AOF文件大小；
最后，我们可以同时使用这两种方式，redis默认优先加载aof文件；

重写是什么回事：
AOF 文件会在操作过程中变得越来越大。比如，如果你做一百次加法计算，最后你只会在数据库里面得到最终的数值(k 100)，但是在你的 AOF 里面会存在 100 次记录，其中 99 条记录对最终的结果是无用的；但 Redis 支持在不影响服务的前提下在后台重构 AOF 文件，让文件得以整理变小；

3.AOF的重写原理

重写时，主进程会fork一个子进程出来进行AOF重写，这个重写过程并不是基于原有的aof文件来做的，而是有点类似于快照的方式，全量遍历内存中的所有数据，然后逐个序列到aof文件中。
在fork子进程这个过程中，服务端仍然可以对外提供服务，在重写aof文件的过程中，主进程的数据更新操作，会缓存到aof_rewrite_buf中，也就是单独开辟一块缓存来存储重写期间收到的操作命令，当子进程重写完以后再把缓存中的数据追加到新的aof文件。
当所有的数据全部追加到新的aof文件中后，把新的aof文件重命名，此后所有的操作都会被写入新的aof文件。如果在rewrite过程中出现故障，不会影响原来aof文件的正常工作，只有当rewrite完成后才会切换覆盖原来那个文件，因此这个 rewrite过程是比较稳定可靠的；