AOF

保存写操作命令到日志的持久化方式，就是Redis里的AOF持久化功能（先写入到内存，再将记录命令写到日志同步到磁盘中）

三种写回策略

• Always，这个单词的意思是「总是」，所以它的意思是每次写操作命令执行完后，同步将 AOF 日志数据写回硬盘；
• Everysec，这个单词的意思是「每秒」，所以它的意思是每次写操作命令执行完后，先将命令写入到 AOF 文件的内核缓冲区，然后每隔一秒将缓冲区里的内容写回到硬盘；
• No，意味着不由 Redis 控制写回硬盘的时机，转交给操作系统控制写回的时机，也就是每次写操作命令执行完后，先将命令写入到 AOF 文件的内核缓冲区，再由操作系统决定何时将缓冲区内容写回硬盘。

写回策略的优缺点

• Always：保证数据的持久性和一致性，但写入性能较低。高可靠

• Everysec：在性能和数据持久性之间做了一定的平衡，适用于大多数应用场景。折中

• No：写入性能最高，但在崩溃时可能会丢失数据，适用于对数据持久性要求不高或可以容忍少量数据丢失的场景。高性能

  

深入底层三种写回策略，其实调用fsync()函数的时机不同：

• Always 策略就是每次写入 AOF 文件数据后，就执行 fsync() 函数；
• Everysec 策略就会创建一个异步任务来执行 fsync() 函数；
• No 策略就是永不执行 fsync() 函数;

AOF 重写机制

为了避免AOF文件越写越大，提供了AOF重写机制，当文件超过阀值就会启动AOF重写机制，来压缩文件，重写机制的妙处在于，尽管某个键值对被多条写命令反复修改，最终也只需要根据这个「键值对」当前的最新状态，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令，这样就减少了 AOF 文件中的命令数量。最后在重写工作完成后，将新的 AOF 文件覆盖现有的 AOF 文件。

AOF后台重写

AOF重写很耗时，所以，Redis 的重写 AOF 过程是由后台子进程 *bgrewriteaof* 来完成的，这么做可以达到两个好处：

• 子进程进行 AOF 重写期间，主进程可以继续处理命令请求，从而避免阻塞主进程；
• 子进程带有主进程的数据副本（数据副本怎么产生的后面会说），这里使用子进程而不是线程，因为如果是使用线程，多线程之间会共享内存，那么在修改共享内存数据的时候，需要通过加锁来保证数据的安全，而这样就会降低性能。而使用子进程，创建子进程时，父子进程是共享内存数据的，不过这个共享的内存只能以只读的方式，而当父子进程任意一方修改了该共享内存，就会发生「写时复制」，于是父子进程就有了独立的数据副本，就不用加锁来保证数据安全。

AOF优缺点

AOF（Append-Only File）持久化是 Redis 的一种持久化机制，它将所有的写操作追加到一个文件中，通过重新执行这些写操作来恢复数据。

AOF 持久化的优点包括：

1. 数据完整性：AOF 持久化可以保证数据的完整性和持久性，每个写操作都会被追加到文件中，从而避免了数据丢失的风险。
2. 灵活性：AOF 持久化采用追加写入的方式，因此可以在不中断服务的情况下进行持久化操作，提供了更好的灵活性。
3. 可读性：AOF 文件是一个追加写入的日志文件，可以通过文本编辑器查看其中的写操作，方便进行故障排查和数据恢复。
4. 高性能：AOF 持久化的写入性能通常比 RDB（Redis 数据库快照持久化）更高，尤其在写入频率较高的场景下。

AOF 持久化的缺点包括：

1. 文件体积较大：AOF 文件相对于 RDB 文件通常会更大，因为它包含了所有的写操作。这可能会占用更多的磁盘空间。
2. 恢复速度较慢：由于 AOF 持久化是通过重新执行写操作来恢复数据的，当 AOF 文件较大时，恢复过程可能比 RDB 持久化更慢。
3. 可能存在数据冗余：由于 AOF 文件记录了所有的写操作，可能会导致一些数据操作的冗余，尤其是在写入频率较高的情况下。

需要根据具体的业务需求、数据安全性和性能要求来选择合适的持久化方式。可以采用 AOF 持久化来提供更好的数据完整性和灵活性，但也要注意管理 AOF 文件的大小和恢复速度。

使用命令

需要使用CONFIG命令来修改appendonly参数的值（Yes/No）

RDB

• AOF文件的内容是操作命令
• RDB文件的内容是二进制数据

Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave，他们的区别就在于是否在「主线程」里执行：

• 执行了 save 命令，就会在主线程生成 RDB 文件，由于和执行操作命令在同一个线程，所以如果写入 RDB 文件的时间太长，会阻塞主线程；
• 执行了 bgsave 命令，会创建一个子进程来生成 RDB 文件，这样可以避免主线程的阻塞；

Redis 的快照是全量快照，也就是说每次执行快照，都是把内存中的「所有数据」都记录到磁盘中。

Redis RDB（Redis Database）是一种快照持久化机制，用于将 Redis 的内存数据保存到磁盘上的二进制文件中。

RDB 持久化的工作原理

1. Redis 通过fork一个子进程来执行持久化操作，父进程继续处理客户端请求。
2. 子进程将当前的内存数据快照写入到临时文件中。
3. 写入完成后，子进程将临时文件重命名为持久化文件（默认名为dump.rdb）。
4. Redis 将旧的持久化文件（如果存在）替换为新的持久化文件。

执行快照时，数据能被修改吗

执行 bgsave 过程中，Redis 依然可以继续处理操作命令的，也就是数据是能被修改的，关键的技术就在于写时复制技术（Copy-On-Write, COW）。

RDB 持久化是通过将 Redis 的内存数据快照写入磁盘的方式来实现的。为了保证数据的一致性，Redis 在执行 RDB 快照时会使用子进程来处理持久化操作，而父进程继续处理客户端请求。在子进程执行 RDB 快照期间，父进程仍然可以处理客户端的写操作。这意味着，在执行 RDB 持久化期间，Redis 可能会接收到新的写操作，并且这些写操作会修改内存中的数据。然而，这些被修改的数据不会被立即写入到 RDB 文件中。子进程在完成 RDB 持久化后，会将当前内存中的数据快照写入到临时文件中，并将临时文件重命名为持久化文件。因此，在 RDB 快照执行期间，写操作对于持久化操作来说是不可见的。

RDB 持久化的优点

1. 性能较高：RDB 持久化是通过将内存数据快照写入磁盘的方式来实现持久化，速度较快，适合大规模数据的备份和恢复。
2. 文件体积较小：RDB 文件是二进制格式，相对于 AOF（Append-Only File）持久化产生的日志文件，文件体积较小，节省磁盘空间。
3. 恢复速度较快：由于 RDB 文件是 Redis 数据的快照，恢复数据时只需加载 RDB 文件即可，速度较快。

RDB 持久化的缺点

1. 可能会丢失数据：RDB 持久化是通过周期性地将内存数据快照写入磁盘来实现的，如果 Redis 在持久化之间发生崩溃，可能会丢失最后一次持久化后的数据。
2. 不适合实时备份：RDB 持久化是通过在后台进行快照操作来实现的，不适合实时备份，因此在数据恢复时可能会丢失最新的数据。

需要根据具体的业务需求、数据安全性和性能要求来选择合适的持久化方式。可以使用 RDB 持久化来提供较高的性能和较小的文件体积，但需要注意定期执行持久化操作以避免数据丢失。

混合持久化

aof-use-rdb-preamble yes

混合持久化工作在AOF日志重写过程

当开启了混合持久化时，在 AOF 重写日志时，fork 出来的重写子进程会先将与主线程共享的内存数据以 RDB 方式写入到 AOF 文件，然后主线程处理的操作命令会被记录在重写缓冲区里，重写缓冲区里的增量命令会以 AOF 方式写入到 AOF 文件，写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。

也就是说，使用了混合持久化，AOF 文件的前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据。这样的好处在于，重启 Redis 加载数据的时候，由于前半部分是 RDB 内容，这样加载的时候速度会很快。加载完 RDB 的内容后，才会加载后半部分的 AOF 内容，这里的内容是 Redis 后台子进程重写 AOF 期间，主线程处理的操作命令，可以使得数据更少的丢失。

大key对持久化的影响

Redis 中的大 key 指的是占用比较大的键值对，通常是字符串类型的值，其大小超过了 Redis 的配置参数 hash-max-ziplist-value（默认为 64 字节）或 list-max-ziplist-value（默认为 8KB）。

大 key 对持久化的影响如下：

1. RDB 持久化：在执行 RDB 持久化时，Redis 会将内存中的数据快照写入到磁盘的 RDB 文件中。如果存在大 key，特别是大字符串类型值，会导致 RDB 文件的大小增加，从而增加持久化操作的耗时和占用的磁盘空间。
2. AOF 持久化：在执行 AOF 持久化时，Redis 会将写操作追加到 AOF 文件中。如果存在大 key，每次对该键进行修改操作时，都会导致 AOF 文件的增长，从而增加持久化操作的耗时和占用的磁盘空间。

大 key 对持久化的影响主要体现在持久化文件的大小和持久化操作的性能上。较大的持久化文件可能会增加恢复数据的时间，而频繁的持久化操作可能会降低 Redis 的写入性能。

为了减少大 key 对持久化的影响，可以考虑以下措施：

• 将大 key 拆分为多个较小的键值对，以减少单个键值对的大小。
• 对于大字符串类型值，可以考虑是否需要拆分为多个较小的字符串进行存储。
• 根据业务需求和数据访问模式，合理设置 Redis 的配置参数，如 hash-max-ziplist-value 和 list-max-ziplist-value，以控制大 key 的大小。