持久化

• Redis是个基于内存的数据库。
• 那服务一旦宕机，内存中的数据将全部丢失。
• 通常的解决方案是从后端数据库恢复这些数据，但后端数据库有性能瓶颈，如果是大数据量的恢复，
  • 1. 会对数据库带来巨大的压力
  • 2. 数据库的性能不如Redis。导致程序响应慢。
• 所以对Redis来说，实现数据的持久化，避免从后端数据库中恢复数据，是至关重要的。

Redis持久化有哪些方式呢？

• RDB
• AOF

RDB-快照方式

• RDB持久化是把当前进程数据生成快照保存到磁盘上的过程，由于是某一时刻的快照，那么快照中的值要早于或者等于内存中的值。
• 触发rdb持久化的方式有2种，分别是手动触发和自动触发。
  • 手动触发：
    • save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存 比较大的实例会造成长时间阻塞，线上环境不建议使用
    • bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子 进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短
  • 自动触发：
    • redis.conf中配置save m n，即在m秒内有n次修改时，自动触发bgsave生成rdb文件；
    • 主从复制时，从节点要从主节点进行全量复制时也会触发bgsave操作，生成当时的快照发送到从节点；
    • 执行debug reload命令重新加载redis时也会触发bgsave操作；
    • 默认情况下执行shutdown命令时，如果没有开启aof持久化，那么也会触发bgsave操作；

RDB-优缺点

• 优点
  • RDB文件是某个时间节点的快照，默认使用LZF算法进行压缩，压缩后的文件体积远远小于内存大小，适用于备份、全量复制等场景；
  • Redis加载RDB文件恢复数据要远远快于AOF方式；
• 缺点
  • RDB方式实时性不够，无法做到秒级的持久化；
  • 每次调用bgsave都需要fork子进程，fork子进程属于重量级操作，频繁执行成本较高；
  • RDB文件是二进制的，没有可读性，AOF文件在了解其结构的情况下可以手动修改或者补全；
  • 版本兼容RDB文件问题；

AOF-日志模式

• Redis是“写后”日志，Redis先执行命令，把数据写入内存，然后才记录日志。日志里记录的是Redis收到的每一条命令，这些命令是以文本形式保存。PS: 大多数的数据库采用的是写前日志（WAL），例如MySQL，通过写前日志和两阶段提交，实现数据和逻辑的一致性。
• 如何实现AOF
  • 默认情况下，Redis是没有开启AOF的，可以通过配置redis.conf文件来开启AOF持久化，关于AOF的配置如下：
    • appendonly 默认情况下AOF功能是关闭的，将该选项改为yes以便打开Redis的AOF功能。
    • appendfilename 配置 AOF文件的名字。
    • appendfsync 同步策略
      • Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
      • Everysec，每秒写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
      • No，操作系统控制的写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

RDB+AOF混合模式

• Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。
• 简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。

从持久化中恢复数据

• 其实想要从这些文件中恢复数据，只需要重新启动Redis即可。
• redis重启时判断是否开启aof，如果开启了aof，那么就优先加载aof文件；
• 如果aof存在，那么就去加载aof文件，加载成功的话redis重启成功，如果aof文件加载失败，那么会打印日志表示启动失败，此时可以去修复aof文件后重新启动；
• 若aof文件不存在，那么redis就会转而去加载rdb文件，如果rdb文件不存在，redis直接启动成功；
• 如果rdb文件存在就会去加载rdb文件恢复数据，如加载失败则打印日志提示启动失败，如加载成功，那么redis重启成功，且使用rdb文件恢复数据；
• 那么为什么会优先加载AOF呢？因为AOF保存的数据更完整，通过上面的分析我们知道AOF基本上最多损失1s的数据。