redis详细教程（5.AOP和RDB持久化）

AOF（Append Only File）日志和RDB（Redis Database Backup）持久化是Redis中两种重要的数据持久化机制。

RDB持久化机制原理RDB是Redis提供的一种数据快照保存机制，它将某个时间点的数据库状态保存到一个RDB文件中。这个文件非常适合用于灾难恢复，因为它是自包含的，并且可以被复制到任何其他支持RDB格式的Redis服务器上。

RDB

RDB的触发方式有两种：

自动触发：Redis可以在配置文件中设置自动保存点，例如save 60 1000，意味着如果60秒内有1000个键被改变，则自动执行快照保存。这是通过比较上一次快照后写操作的数量来决定是否触发新的快照。
手动触发：用户可以通过发送SAVE或BGSAVE命令来手动触发RDB快照。SAVE命令会阻塞Redis直到快照完成，而BGSAVE命令会在后台异步执行快照，不会阻塞主线程。

当Redis配置了RDB持久化并且满足触发条件后，它会执行以下步骤来创建RDB快照文件：

1.Fork子进程

Redis主进程会调用fork()系统调用创建一个子进程。这个操作是原子的，并且开销很小，因为它仅复制父进程的内存页面，而不会复制实际的数据，子进程会共享父进程的数据，这意味着它能够访问相同的数据集，而不需要额外的内存消耗。

2.生成RDB文件

子进程开始将内存中的数据序列化到一个RDB文件中。这个序列化过程包括将键值对、集合、有序集合、哈希表等数据结构转换为特定的格式，并写入到磁盘上的RDB文件中，这个过程中，子进程会锁定内存中的数据，以确保数据的一致性。但由于数据是共享的，主进程仍然可以继续处理客户端的请求，只是对新修改的数据不进行锁定。

3.替换旧的RDB文件

一旦RDB文件创建完成，子进程会将新的RDB文件重命名为与旧的RDB文件相同的文件名，通常这个过程涉及到一个临时文件的重命名操作。

4.清理子进程

子进程完成RDB文件的创建后，会退出。操作系统会清理子进程使用的资源。

配置持久化：

1.设置自动保存点

设置在60秒内至少有1000个键被改变时自动保存数据：

复制代码

save 60 1000

2.启用或禁用RDB持久化：

复制代码

save ""

通过这些配置，你可以灵活地控制Redis的RDB持久化行为，以满足不同的业务需求和数据安全要求。

AOP

AOF通过记录Redis服务器接收到的每条写命令来记录数据变化，并将这些命令追加到AOF文件中，为了避免AOF文件过大，Redis会定期对AOF文件进行重写，只保留必要的命令，这个过程称为AOF重写。

当触发AOF重写时，Redis会fork出一个子进程来处理AOF文件的重写，以防止主进程阻塞无法提供服务，子进程遍历Redis内存快照中的数据并写入临时AOF文件，同时主线程会将新的写指令写入aof_buf和aof_rewrite_buf两个重写缓冲区。

子进程结束临时AOF文件写入后，通知主进程，主进程会将aof_rewrite_buf缓冲区中的数据写入到子进程生成的临时AOF文件中，主进程使用临时AOF文件替换旧AOF文件，完成整个重写过程。

文件写入策略：

appendfsync配置项控制将aof_buf中的数据同步到磁盘的策略，有三种选项：Always、Everysec、No。

Always：每个写命令执行完，立马同步地将日志写回磁盘；数据基本不丢失，性能较差。
Everysec：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；宕机时丢失1秒内的数据，性能较好。
No：由操作系统控制何时将缓冲区内容写回磁盘；宕机时丢失数据较多，通常同步周期最长30秒。

持久化数据恢复：

当Redis重启时，会直接从appendonly.aof文件中读取日志，恢复Redis内存数据。通过这些机制，AOF持久化确保了Redis的数据安全性和一致性，同时提供了灵活的数据恢复能力。

优缺点

AOF和RDB持久化的优缺点如下：

RDB数据不完整，两次备份之间会丢失数据；AOF相对完整，取决于刷盘策略。RDB会有压缩，占用内存小；而AOF记录命令，文件体积很大。RDB宕机恢复速度很快，而AOF慢，因为要执行一遍命令。通常，为了结合RDB的快速数据恢复能力和AOF的数据安全性，实际开发中往往会同时使用两者来确保数据的安全性和快速恢复。