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的数据安全性,实际开发中往往会同时使用两者来确保数据的安全性和快速恢复。