no， 依赖操作系统来执行（一般大概30s一次的样子），安全性最低，性能最高，丢失操作系统最后一次对AOF文件触发SAVE操作之后的数据
AOF通过保存命令来持久化，随着时间的推移，AOF文件会越来越大，Redis通过AOF文件重写来解决AOF文件不断增大的问题（可以减少文件的磁盘占有量，加快数据恢复的速度），原理如下：
调用fork，创建一个子进程
子进程读取当前数据库的状态来“重写”一个新的AOF文件（这里虽然叫“重写”，但实际并没有对旧文件进行任何读取，而是根据数据库的当前状态来形成指令）
主进程持续将新的变动同时写到AOF重写缓冲区与原来的AOF缓冲区中
主进程获取到子进程重写AOF完成的信号，调用信号处理函数将AOF重写缓冲区内容写入新的AOF文件中，并对新文件进行重命名，原子地覆盖原有AOF文件，完成新旧文件的替换
AOF的重写也分为手动触发与自动触发
手动触发： 直接调用bgrewriteaof命令 自动触发： 根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。其中auto-aof-rewrite-min-size表示运行AOF重写时文件最小体积，默认为64MB。auto-aof-rewrite-percentage表示当前AOF文件大小（aof_current_size）和上一次重写后AOF文件大小（aof_base_size）的比值。自动触发时机为 aof_current_size > auto-aof-rewrite-min-size &&（aof_current_size - aof_base_size）/aof_base_size> = auto-aof-rewrite-percentageRDB vs AOF
RDB与AOF两种方式各有优缺点。
RDB的优点：与AOF相比，RDB文件相对较小，恢复数据比较快（原因见数据恢复部分） RDB的缺点：服务器宕机，RBD方式会丢失掉上一次RDB持久化后的数据；使用bgsave fork子进程时会耗费内存。 AOF的优点： AOF只是追加文件，对服务器性能影响较小，速度比RDB快，消耗内存也少，同时可读性高。 AOF的缺点：生成的文件相对较大，即使通过AOF重写，仍然会比较大；恢复数据的速度比RDB慢。数据库的恢复
服务器启动时，如果没有开启AOF持久化功能，则会自动载入RDB文件，期间会阻塞主进程。如果开启了AOF持久化功能，服务器则会优先使用AOF文件来还原数据库状态，因为AOF文件的更新频率通常比RDB文件的更新频率高，保存的数据更完整。
redis数据库恢复的处理流程如下，
在数据恢复方面，RDB的启动时间会更短，原因有两个：
RDB 文件中每一条数据只有一条记录，不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了，文件相对较小。
RDB 文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作，所以在CPU消耗上要远小于AOF日志的加载。
