REDIS概述用作存储数据库。通常，数据存储在内存中，并且读取操作基于内存中的数据，但这也意味着如果服务器异常丢失，则意味着。
如果它取决于外部力以进行数据恢复，则成本很高，效率很低，REDIS本身提供了数据持久性技术。服务器异常出现后，它可以在停机时间之前快速恢复数据。
REDIS提供了两种持久机制：AOF（仅附加文件），记录的数据更改RDB RDB（REDIS数据库），并记录了数据库数据快照信息。复制不同的使用方案。本文主要描述实现原理和优势和优势和缺点AOF持续机制。
AOF的实际REDIS版本为5.0.8。默认的AOF耐用性已关闭。修改redis.conf配置以打开它：
：设置日志的日志策略，默认值为每个sec（下面的几个回编策略之间的差异）：
为自动重写日志设置触发条件：
配置完成后，重新启动Redis服务器，并通过客户端执行写作命令：
相应的目录（默认值是当前用户的主要目录）未生成附录。通过在顺序上显示执行日志，触发了日志文件的生成；
这个问题可能与Redis的持久机制有关（首先埋入坑）。
实施原理AOF日志包括两个核心点：
在回编策略时，重写性能和可靠性的权量日志时，在控制记录返回策略的日志后记录时，redis记录了aof log，当日志更新与磁盘同步时，这取决于书写策略。
REDIS提供了三种类型的撰写策略，以应付不同方案的需求。在redis.conf中，您可以配置书写策略：
始终同步写回：编写事件的每个过程都会同步将日志更新同步到磁盘。就日志完整性而言，这是最可靠的策略。当然，它对性能也具有最大的影响；同时将日志刷到磁盘上，这是在性能和可靠性平衡下的最佳策略；无操作系统控制回编写：当操作系统决定同步更新日志时，最可靠的可靠性是最差的，但性能最佳；日志中的日志是，如果连续扩展AOF日志的卷，则会发生以下问题：
文件系统本身对文件大小有限制。当文件太大时不能保留太大的文件，并且内部添加内容将非常慢，因此REDIS提供了AOF日志重写机制来控制日志文件的大小。它需要解决以下问题：
如何有效地控制非封锁日志的重写机制，以及如何确保日志数据完整性日志的日志记录不影响客户端写作操作。过程的过程是重写机制的实现原理：
通过Fork子过程的过程，Redis将根据数据库重写的状态在后台生成REDIS数据副本。与父进程相同的内存空间。只有当数据在父亲过程中更改时，它才会打开新的内存空间并生成日志和重写的实际数据复制。新日志文件。在重写，旧日志文件将正常编写，以便即使重写异常，也不会影响整体日志的完整性。首先，为什么重写日志，可以有效地控制日志文件的大小？
例如：因为重写AOF日志时，它基于数据库的当前状态，因此可以省略该过程中生成的许多指令。只需生成当前数据状态所需的写作指令即可。
REDIS可以在不阻止主线程的正常工作的情况下重写日志。这样，还有另一个问题：在子过程中的日志重写期间，主过程已更改数据，并且重写日志无法感知到在此期间的更改，如下图所示：：
数据在Time-2上进行了修改，日志重复依赖性是Time-1 Time快照数据。
REDIS通过编写两个缓冲数据来解决此问题：
在重写期间，数据更改将同时写入AOF重写缓冲区中，以记录重写期间发生的数据更改。重写完成后，将在重写缓冲区中记录的更改添加到重写以重写日志的末尾，以这种方式解决日志数据完整性问题。
优势和缺点如下：
AOF更可靠。不同的写作策略使用户可以根据使用方案灵活选择。默认的每秒记录策略将确保良好的性能。即使存在异常的停机时间，它也只会丢失1S日志数据AOF日志。内容以REDIS协议格式保存，因此日志具有很高的可读性，并且更容易分析日志的缺点：如下：
在同一数据集的情况下，AOF文件通常大于RDB文件。如果还有另一种重写机制可以控制日志文件，则数据更改在重写期间发生，它将比平常占用更多的内存。在通过日志缓冲区重新启动数据服务器后，通过重新定位数据恢复的数据恢复在AOF登录中写入说明。如果AOF文件太大，则会导致整体恢复时间需要很长时间。
原始：https：//juejin.cn/post/7098142267453472799