我要评论概述
redis 提供 rdb 和 aof 两种持久化机制，它们在数据安全性、性能、恢复速度等方面有显著差异。
为什么要进行持久化？如果是大数据量的恢复，会有下述的影响
- 会对数据库带来巨大的压力，
- 数据库的性能不如redis。导致程序响应慢
- 实现数据的持久化，避免从后端数据库中恢复数据
rdb（redis database）
核心原理
rdb持久化是把当前进程数据生成快照保存到磁盘上的过程，由于是某一时刻的快照，那么快照中的值要早于或者等于内存中的值
rdb文件默认为当前工作目录下的dump.rdb，可以根据配置文件中的dbfilename和dir设置rdb的文件名和文件位置
触发方式
有下述两种触发方式
- 手动触发：分别对应save和bgsave命令
- 自动触发：以下4种情况时会自动触发
手动触发
- 手动触发：分别对应save和bgsave命令
- save命令：阻塞当前redis服务器，直到rdb过程完成为止，对于内存 比较大的实例会造成长时间阻塞，线上环境不建议使用
- bgsave命令：redis进程执行fork操作创建子进程，rdb持久化过程由子 进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短
fork()是由操作系统提供的函数，作用是创建当前进程的一个副本作为子进程
fork一个子进程，子进程会把数据集先写入临时文件，写入成功之后，再替换之前的rdb文件，用二进制压缩存储，这样可以保证rdb文件始终存储的是完整的持久化内容
自动触发
自动触发：以下4种情况时会自动触发
redis.conf中配置save m n，即在m秒内有n次修改时，自动触发bgsave生成rdb文件；
save <seconds> <changes>
表示在seconds秒内，至少有changes次变化，就会自动触发gbsave命令
- 主从复制时，从节点要从主节点进行全量复制时也会触发bgsave操作，生成当时的快照发送到从节点
- 执行debug reload命令重新加载redis时也会触发bgsave操作；
- 默认情况下执行shutdown命令时，如果没有开启aof持久化，那么也会触发bgsave操作；
aof（append-only file）
针对rdb不适合实时持久化的问题，redis提供了aof持久化方式来解决.
核心原理
aof日志采用写后日志，即先写内存，后写日志
- aof持久化会把被执行的写命令写到aof文件的末尾，记录数据的变化。
- 默认情况下，redis是没有开启aof持久化的，
- 开启后，每执行一条更改redis数据的命令，都会把该命令追加到aof文件中，这是会降低redis的性能，但大部分情况下这个影响是能够接受的，
- 另外使用较快的硬盘可以提高aof的性能
配置方式
通过配置redis.conf文件开启aof持久化
# appendonly参数开启aof持久化 appendonly no # aof持久化的文件名，默认是appendonly.aof appendfilename "appendonly.aof" # aof文件的保存位置和rdb文件的位置相同，都是通过dir参数设置的 dir ./ # 同步策略 # appendfsync always appendfsync everysec # appendfsync no # aof重写期间是否同步 no-appendfsync-on-rewrite no # 重写触发配置 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 加载aof出错如何处理 aof-load-truncated yes # 文件重写策略 aof-rewrite-incremental-fsync yes
aof实现步骤
aof需要记录redis的每个写命令，步骤为：
命令追加（append）：启aof持久化功能后，服务器每执行一个写命令，都会把该命令以协议格式先追加到aof_buf缓存区的末尾
不是直接写入文件，避免每次有命令都直接写入硬盘，减少硬盘io次数
文件写入（write），文件同步（sync）：何时把aof_buf缓冲区的内容写入保存在aof文件中，redis提供了多种策略，appendfsync选项的默认配置为everysec，即每秒执行一次同步
appendfsync always：将aof_buf缓冲区的所有内容写入并同步到aof文件，每个写命令同步写入磁盘appendfsync everysec：将aof_buf缓存区的内容写入aof文件，每秒同步一次，该操作由一个线程专门负责appendfsync no：将aof_buf缓存区的内容写入aof文件，什么时候同步由操作系统来决定
aof的同步策略是涉及到操作系统的write函数和fsync函数的
aof重写
基本概念
aof会记录每个写命令到aof文件，随着时间越来越长，aof文件会变得越来越大。
为了解决aof文件体积膨胀的问题，redis提供aof文件重写机制来对aof文件进行“瘦身”。
aof重写的目的就是减小aof文件的体积
redis通过创建一个新的aof文件来替换现有的aof，新旧两个aof文件保存的数据相同，但新aof文件没有了冗余命令
- 时间长了，aof文件中通常会有一些冗余命令，
- 比如：过期数据的命令、无效的命令（重复设置、删除）、多个命令可合并为一个命令（批处理命令）。
- 所以aof文件是有精简压缩的空间的
触发方式
文件重写可分为手动触发和自动触发，
- 手动触发执行bgrewriteaof命令，该命令的执行跟bgsave触发快照时类似的，都是先fork一个子进程做具体的工作
- 自动触发会根据auto-aof-rewrite-percentage和auto-aof-rewrite-min-size 64mb配置来自动执行bgrewriteaof命令
重写过程
aof重写过程是由后台进程bgrewriteaof来完成的。
- 主线程fork出后台的bgrewriteaof子进程，fork会把主线程的内存拷贝一份给bgrewriteaof子进程，这里面就包含了数据库的最新数据。
- 然后，bgrewriteaof子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。
- 所以aof在重写时，在fork进程时是会阻塞住主线程的
重写过程总结为：“一个拷贝，两处日志”。在fork出子进程时的拷贝，以及在重写时，如果有新数据写入，主线程就会将命令记录到两个aof日志内存缓冲区中。
- 而在bgrewriteaof子进程完成会日志文件的重写操作后，会提示主线程已经完成重写操作，主线程会将aof重写缓冲中的命令追加到新的日志文件后面
- 这时候在高并发的情况下，aof重写缓冲区积累可能会很大，这样就会造成阻塞，redis后来通过linux管道技术让aof重写期间就能同时进行回放，这样aof重写结束后只需回放少量剩余的数据即可
- 最后通过修改文件名的方式，保证文件切换的原子性
- 在aof重写日志期间发生宕机的话，因为日志文件还没切换，所以恢复数据时，用的还是旧的日志文件
重写过程中主线程有哪些地方会被阻塞？
fork子进程时，需要拷贝虚拟页表，会对主线程阻塞。
主进程有bigkey写入时，操作系统会创建页面的副本，并拷贝原有的数据，会对主线程阻塞。
子进程重写日志完成后，主进程追加aof重写缓冲区时会对主线程阻塞
为什么不复用原aof日志
子进程写同一个文件会产生竞争问题，影响父进程的性能。
如果aof重写过程中失败了，相当于污染了原本的aof文件，无法做恢复数据使用
rdb vs aof
| 维度 | rdb | aof |
|---|---|---|
| 数据安全性 | 低（依赖快照周期） | 高（可配置秒级同步） |
| 性能影响 | 低（后台异步） | 中高（同步写盘/重放命令） |
| 恢复速度 | 快（直接加载二进制） | 慢（逐条执行命令） |
| 文件体积 | 小（压缩存储） | 大（需重写优化） |
| 适用场景 | 容灾备份/快速恢复 | 金融级数据安全要求 |
redis 4.0 中提出了一个混合使用 aof 日志和内存快照的方法。简单来说，内存快照以一定的频率执行，在两次快照之间，使用 aof 日志记录这期间的所有命令操作
aof 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销
这个方法既能享受到 rdb 文件快速恢复的好处，又能享受到 aof 只记录操作命令的简单优势, 实际环境中用的很
如何保证数据一致性
rdb中的核心思路是copy-on-write，来保证在进行快照操作的这段时间，需要压缩写入磁盘上的数据在内存中不会发生变化。
- 一方面redis主进程会fork一个新的快照进程专门来做这个事情，这样保证了redis服务不会停止对客户端包括写请求在内的任何响应。
- 另一方面这段时间发生的数据变化会以副本的方式存放在另一个新的内存区域，待快照操作结束后才会同步到原来的内存区域
例如：
- 如果主线程要修改一块数据（例如图中的键值对 c），那么，这块数据就会被复制一份，生成该数据的副本。
- 然后，bgsave 子进程会把这个副本数据写入 rdb 文件，
- 而在这个过程中，主线程仍然可以直接修改原来的数据。
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持代码网。
发表评论