redis持久化——AOF Redis

AOF AOF（append only file）持久化是以独立日志的方式记录每次写命令。该功能默认不会开启，开启的话，需要在配置文件中追加appendonly yes文件名称需要通过appendfilename配置，默认的文件名称为appendonly.aof。文件的保存路径和RDB的配置方式一致，使用dir命令。
AOF流程

文章图片

所有的写入命令会追加到aof buf（缓冲区）中。
AOF缓冲区根据对应的策略向硬盘做同步操作。
随着AOF文件的不断增加，会定期对AOF文件进行重写。
当Redis服务器重启时，可以加载AOF文件进行数据恢复。

文件同步
Redis提供多种AOF缓冲区同步文件策略，由参数appendfsync控制

可配置值	说明
always	命令写入到aof_buf后调用系统的fsync操作同步到AOF文件，fsync完成后线程返回。
everysec	命令写入到aof_buf后调用系统的write操作，write完成后线程返回。fsync同步文件操作由专门线程每秒调用一次。
no	命令写入到aof_buf后调用系统的write操作，不对AOF文件做fsync同步，同步硬盘操作由操作系统负责，通常同步周期最长30秒。

系统调用write和fsync说明：

write操作会触发延迟写机制。linux在内核提供缓冲区用来提高硬盘IO性能。write操作在写入系统缓冲区后直接返回。同步硬盘操作依赖于系统调度机制。
fsync针对单个文件操作，做强制硬盘同步，fsync将阻塞直到写入硬盘完成后返回，保证了数据持久化。

always，everysec和no配置方式说明：

配置为always，每次写入都要同步AOF文件，在一般SATA硬盘上，Redis只能支持大约几百TPS写入，显然和Redis高性能特性背道而驰，不建议配置。
配置为no，由于操作系统每次同步AOF文件的周期不可控，而且会加大每次同步硬盘的数据量，虽然提高了性能，但是数据的安全性无法保证。
配置为everysec，是建议的同步策略，也是默认的配置策略。能够做到性能兼容和数据安全性。

重写机制
AOF重写可以分为手动触发和自动触发

手动触发：直接调用bgrewriteaof命令。
自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。
- auto-afo-rewrite-min-size：表示运行AOF重写时文件最小体积，默认为64MB
- auto-aof-rewrite-percentage:代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比值。这两个参数可以通过info persistence统计信息中查看。

自动触发时机=aof_current_size > auto-aof-rewrite-min-size && (aof_current_size - aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage。
AOF文件重写流程说明

文章图片

【redis持久化——AOF】流程说明：
? 1，执行AOF重写流程，如果当前进程正在执行AOF重写，请求不执行，直接返回；如果当前进程在执行bgsave操作，重写命令延迟到bgsave完成后执行。
? 2，父进程fork子进程，开销和RDB中的fork等同。
? 3.1，fork出子进程后，父进程继续响应其他请求。所有修改命令依然写入到aof缓冲区中并根据同步策略appendfsync策略同步到硬盘，保证原有AOF机制正确性。
? 3.2，由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然在响应请求，所以这段时间内的写入数据都是存放在AOF重写缓冲区中，防止新AOF文件生成时候丢失这部分数据。
? 4，子进程根据内存快照，按照命令合并规则写入到新的AOF文件中。
? 5.1，新AOF文件写入完成后，子进程发送信号给父进程。
? 5.2，父进程把AOF重写缓冲区的数据写入到新的AOF文件中。
? 5.3，使用新AOF文件替换老文件，完成AOF重写。
重启加载
AOF和RDB文件都可以用于Redis重启的数据恢复，要是这两者都存在的情况下，如何恢复？