2024年最新Redis—持久化(5)，2024年最新完整PDF

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

• 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日志重写过程

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

(https://bbs.csdn.net/topics/618658159)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！