【Redis】持久化操作（RDB、AOF）——分布式缓存（一）

相关内容：
【Redis】集群（主从模式、哨兵模式、分片集群）——分布式缓存（二）：https://blog.csdn.net/lucas161543228/article/details/125159749?spm=1001.2014.3001.5501

一、为什么需要实现Redis分布式缓存

单点Redis存在的问题及解决方案：

• 数据丢失问题
  解决方案：实现Redis数据持久化
• 并发能力问题
  解决方案：搭建主从集群，实现读写分离
• 存储能力问题
  解决方案：搭建分片集群，利用插槽机制实现动态扩容
• 故障恢复问题
  解决方案：利用Redis哨兵，实现健康检测和自动恢复

二、Redis持久化

主要有两种方式：RDB和AOF（Append-only-file）。
1、RDB
RDB会将Redis当前的数据以快照的形式保存在一个名为dump.rdb的二进制文件中（在Redis配置文件中可以修改文件名和文件保存路径）。
简单来说，就是将当前时刻的Redis数据保存下来。
有两种方式可以触发RDB：手动触发和自动触发。

手动触发
执行save或bgsave命令来手动触发RDB。
两者的区别在于：

• save命令执行期间会阻塞所有Redis请求，当Redis服务储存大量数据时，会造成较长时间的阻塞，不建议使用。
• 而bgsave会fork一个子进程来完成持久化操作，在命令执行期间仍然可以相应客户端请求。执行bgsave命令时，Redis服务的阻塞只发生在fork阶段，一般情况时间很短（可以说bgsave不会阻塞Redis服务）。推荐使用bgsave命令。

bgsave命令的执行流程：

划重点：首先fork一个子进程来完成实际的“保存快照”操作；子进程会生成一个临时的rdb文件，待整个持久化过程都结束了，再用这个临时文件替换原有的rdb文件。
看张图理解一下：

bgsave基于COW（Copy-On-Write）技术实现：
前面提到bgsave会fork一个子进程来完成“保存快照”操作，而主进程还可以继续执行其他命令。
此时，如果主线程处理的命令都是读操作，则bgsave线程不受影响。但如果主线程处理的是写操作，则会对该命令操作后的数据复制一份，生成副本，bgsave线程会把这个副本写入到dump.rdb文件中，在这个过程中，主线程仍可执行命令。
由于这些副本的存在，所以bgsave命令可能会消耗额外内存。此外，fork操作也会造成额外的内存消耗。

补充：

• 可以通过lastsave查看最后一次成功执行RDB的时间。
• flushall命令会生成一个空的dump.rdb文件。flush all。
• 对于存储到磁盘中的快照，可以设置是否进行压缩（会消耗CPU性能）。
• 在存储快照后，可以让Redis检查数据完整性（在Redis配置文件中进行配置）。

自动触发

• 在配置文件中设置：save M N，代表“在M秒内，如果数据被修改了N次，就触发一次bgsave操作”。默认配置为：
  
• 当从节点做全量复制时，主节点会自动执行bgsave操作，并且把生成的RDB文件发送给从节点。
• 执行debug reload命令时，也会自动触发bgsave操作。
• 执行shutdown命令时，如果没有开启AOF持久化也会自动触发bgsave操作。

RDB的优缺点

• 优点：
  
• 缺点：
  

2、AOF
AOF以日志的形式来记录每个写操作（增量保存，只许追加文件，不可以改写文件），将Redis执行过的所有写指令记录下来（不记录读指令），Redis启动的时候，会读取AOF文件并依次执行文件中的指令，以完成数据的恢复工作。
AOF持久化流程
①写命令会被追加（append）到AOF缓冲区内。
②根据AOF持久化策略（包括always,everysec,no），将AOF缓冲区的内容同步（sync）到磁盘的AOF文件中。
③手动执行重写命令或者AOF文件大小超过重写策略时，对AOF文件进行重写（rewrite），压缩AOF文件容量。
④Redis服务重启时，重新加载（load）AOF文件中的写命令，以恢复数据。

AOF在Redis中默认不开启，如果要使用AOF，可以在Redis配置文件中进行设置，

AOF持久化策略

默认使用的是everysec，也建议使用everysec。

AOF重写
AOF文件中可能存在多条无效的写指令，比如命令1~命令10都是给同一个变量赋值，那么实际有效的只有最后一条命令，我们没有必要执行前面9条命令，而这些指令却使得AOF文件变得太大，而且在数据恢复时也浪费了多余的时间去执行它们。
因此，我们会对AOF文件进行一个重写，AOF会把这些多余指令去掉，只保留有效的指令。此外，AOF还会把多条指令压缩成同一条指令（比如给多个变量赋值，如果原先写入的是多条set指令，重写的时候就会被合并成一条mset指令），且AOF还会把文件进行编码以进一步压缩空间。
总之，我们只要知道重写操作能够压缩AOF文件的大小，就够了。
可以手动进行重写，也可以设置重写策略来自动重写：

• 手动重写：使用bgrewriteaof命令。
• 自动重写：
  AOF重写的原理
  与bgsave类似，会fork一个子进程。这个子进程会先生成一个临时文件，最后再用临时文件替换原有文件。
  在重写过程中，主进程仍然可以对外服务。如果在重写过程中主线程接收到写命令，会先将写命令写入到aof_buf缓冲区中，当子进程的重写操作完成之后，再把aof_bur缓冲区的内容写入新的aof文件中。

AOF重写的执行流程


AOF的优缺点

• 优点：
  
• 缺点：
  
  3、总结
  
  

参考资料：

• https://blog.csdn.net/heihaozi/article/details/105264477?spm=1001.2014.3001.5502
• https://blog.csdn.net/nianqrzhanghw/article/details/121163780?spm=1001.2014.3001.5502
• https://www.bilibili.com/video/BV1Rv41177Af?spm_id_from=333.337.search-card.all.click