本文主要深入了解RDB和AOF这两种持久化的逻辑和原理，喜欢的朋友欢迎点赞，写得不对的也请大佬多多批评和指正，以期共同进步，谢谢啦。
image
RDB的原理
RDB持久化存储即是将redis存在内存中的数据以快照的形式保存在本地磁盘中
RDB持久化的优势与劣势
优势
- 文件实现的数据快照，全量备份，便于数据的传输.比如我们需要把A服务器上的备份文件传输到B服务器上面，直接将rdb文件拷贝即可.
- 文件采用压缩的二进制文件，当重启服务时加载数据文件，比aof方式更快.
劣势
- rbd采用加密的二进制格式存储文件，由于Redis各个版本之间的兼容性问题也导致rdb由版本兼容问题导致无法再其他的Redis版本中使用.
- 时效性差，容易造成数据的不完整性.因为rdb并不是实时备份，当某个时间段Redis服务出现异常，内存数据丢失，这段时间的数据是无法恢复的，因此易导致数据的丢失.
手动备份
手动备份通过 save 命令和 bgsave 命令。save是同步阻塞，而 bgsave 是非阻塞(阻塞实际发生在 fork 的子进程中)。因此，在我们实际过程中大多是使用bgsave命令实现备份
自动备份
- 修改配置项 save m n即表示在 m 秒内执行了 n 次命令则进行备份.
- 当Redis 从服务器项主服务器发送复制请求时，主服务器则会使用 bgsave命令生成 rbd 文件，然后传输给从服务器.
- 当执行 debug reload 命令时也会使用 save 命令生成rdb文件.
- 当使用 shutdown 命令关掉服务时，如果没有启用 aof方式实现持久化则会采用bgsave的方式做持久化.同时shutdown后面可以加备份参数[nosave|save]
bgsave持久化存储实现原理
image
- 执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如果存在则直接返回.
- 父进程fork一个子进程(fork的过程中会造成阻塞的情况),这个过程可以使用info stats命令查看latest_fork_usec选项,查看最近一次fork操作小号的时间,单位是微妙.
- 父进程fork完之后,则会返回Background saving started信息提示,此时fork阻塞解除.
- fork出的子进程开始根据父进程内存数据生成临时的快照文件，然后替换原文件.使用lastsave命令可以查看最后一次生成rdb的时间，对应info的rdb_last_save_time选项.
- 当备份完毕之后向父进程发送完成信息
RDB文件保存过程
- redis调用fork,现在有了子进程和父进程。
- 父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的写时复制机制(copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照。、
- 当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出
fork 操作会阻塞，导致Redis读写性能下降。我们可以控制单个Redis实例的最大内存，来尽可能降低Redis在fork时的时间消耗;或者控制自动触发的频率减少fork次数
AOF的原理
AOF的整个流程大体来看可以分为两步，一步是命令的实时写入(如果是 appendfsync everysec 配置，会有1s损耗)，第二步是对aof文件的重写
- 命令写入
- 追加到aof_buf
- 同步到aof磁盘
AOF的优缺点
优点
- 多种文件写入(fsync)策略.
- 数据实时保存，数据完整性强.即使丢失某些数据，制定好策略最多也是一秒内的数据丢失.
- 可读性强，由于使用的是文本协议格式来存储的数据,可有直接查看操作的命令，同时也可以手动改写命令.
缺点
文件体积过大，加载速度比rbd慢.由于aof记录的是redis操作的日志,一些无效的，可简化的操作也会被记录下来,造成aof文件过大.但该方式可以通过文件重写策略进行优化.
AOF持久化存储实现原理
image
- redis命令写入，此时会将redis命令写入aof_buf换从区.
- 缓冲区中数据根据备份策略实现写入日志文件.
- 当aof的文件越来越庞大，会根据我们的配置策略来实现aof的重写，实现文件的压缩，减少体积.
- 当redis重新启动时，在去重写加载aof文件，达到数据恢复的目的.
选择AOF还是RDB进行数据的持久化
- 针对不同的情况来选择，建议使用两种方式相结合.
- 针对数据安全性、完整性要求高的采用aof方式.
- 针对不太重要的数据可以使用rdb方式.
- 对于数据进行全量备份，便于数据备份的可以采用rdb方式.
欢迎关注微信公众号【慕容千语】
