共计 889 个字符，预计需要花费 3 分钟才能阅读完成。
介绍
Redis 是内存型数据库，一旦主过程退出就会造成数据失落。它的长久化次要有两大机制，即 AOF 日志和 RDB 快照，本文次要关怀 AOF 日志。
过程
Redis 执行完一个写命令后，将写命令以协定文本的模式追加到 AOF 缓冲区开端，再通过 同步策略 来决定是否将 AOF 缓冲区中的内容写入 & 同步到 AOF 日志。
同步策略
AOF 机制提供了三个抉择，也就是配置项 appendfsync 的三个可选值：
- always：将
AOF缓冲区中的所有内容 写入 并同步 到AOF日志。 - everysec：将
AOF缓冲区中的所有内容 写入 到AOF日志，如果上次同步AOF日志的工夫间隔当初超过 1 秒钟，那么对AOF日志进行 同步。 - no：将
AOF缓冲区中的所有内容 写入 到 AOF 日志，但并不对 AOF 日志进行 同步，何时同步由操作系统来决定。
三种策略的优缺点也不言而喻了，always 可靠性高性能低、no 可靠性低性能高，everysec 取两者折中。
重写机制
AOF 日志是以文件的模式记录接管到的所有写命令。随着接管的写命令越来越多，文件体积会越来越大。这也就意味着会带来一些问题。
- 操作系统对文件体积有限度，不能保留过大的文件。
- 对体积比拟大的文件进行追加写入，效率会升高。
AOF日志体积过大，故障复原过程迟缓。
为了解决下面的问题，Redis 提供了重写性能。通过该性能，Redis 能够创立一份新的 AOF 日志来代替现有的 AOF 日志。
- 两份
AOF日志所保留的数据库状态雷同。 - 新
AOF日志不会蕴含节约空间的冗余命令。 - 新
AOF日志体积小于等于原AOF日志。
重写过程
为什么要放在子过程里执行？
不会造成主线程阻塞，子过程进行 AOF 重写期间，主线程能够持续解决命令申请。
重写过程中有写命令，会造成数据不统一吗？
不会，Redis 保护了 AOF 重写缓冲区，在主线程创立重写子过程后开始应用。如果重写期间有写命令申请，Redis 会追加写入 AOF 缓冲区和 AOF重写缓冲区。当子过程实现创立新 AOF 日志后，主线程会将 AOF 重写缓冲区中的所有内容追加写入新 AOF 日志，此时新旧两份 AOF日志所保留的数据库状态完全一致。最初，用新 AOF 日志笼罩旧 AOF 日志，实现 AOF 日志重写操作。