Redis 持久化

RDB

RDB 启动方式—— save指令

• 命令

save

• 作用：手动执行一次保存
• 结果：会生成一个.rdb文件，保存当前的快照信息

RDB 启动方式——save 指令相关配置

• dbfilename dump.rdb
  • 说明：设置本地数据库文件名，默认值为 dump.rdb
  • 经验：通常设置为 dump.端口号.rdb
• dir
  • 说明：设置存储.rdb 文件的路径
  • 经验：通常设置成存储空间较大的目录中，目录名为data
• rdbcompression yes
  • 说明：设置存储至本地数据库时是否压缩数据，默认为yes，采用LZF压缩
  • 经验：通常默认为开启状态，如果设置为no，可以节省CPU 运行时间，但会使存储的文件变大
• rdbchecksum yes
  • 说明：设置是否进行RDB 文件格式校验，该校验过程在写文件和读文件过程均进行
  • 经验：通常默认为开启状态，如果设置为no，可以节约读写性过程约10% 时间消耗，但是存储一定的数据损坏风险

RDB 启动方式—— save 指令工作原理

注意：save 指令的执行会阻塞当前redis 服务器，直到当前RDB 过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用

解决由于redis 单线程执行save 指令造成的阻塞问题：

• 后台执行—— bgsave 指令

RDB 启动方式—— bgsave 指令

• 命令

bgsave

• 作用：手动启动后台保存操作，但不是立即执行
• bgsave 指令工作原理

         注意：bgsave 命令是针对save 阻塞问题做的优化，redis 内部所有涉及到RDB 操作都采用

                    bgsave 的方式，save 命令可以放弃使用。

• 相关配置
  • stop-writes-on-bgsave-error yes
    • 说明：后台存储过程中如果出现错误现象，是否停止保存操作
    • 经验：通常默认为开启状态

RDB 启动方式—— 自动执行（save 配置）

• 自动执行需要进行配置
  • save second changes
• 作用：满足限定时间范围内key 的变化数量达到指定数量即进行持久化
• 参数：
  • second：监控时间范围
  • changes：监控key 的变化量
• 原理

注意：

• save 配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的
• save 配置中对于second 与 changes 设置通常具有互补对应关系，尽量不要设置成包含性关系
• save 配置启动后执行的是bgsave 操作

RDB 优缺点

• 优点
  • RDB 是一个紧凑压缩的二进制文件，存储效率高
  • RDB 内部存储的是redis 某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
  • RDB 恢复数据的速度要比AOF 快很多
  • 应用：服务器中每X个小时执行bgsave 备份，并将RDB 文件拷贝到远程机器中，用于灾难恢复
• 缺点
  • RDB 方式无论执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
  • bgsave 指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能
  • redis 的总多版本中未进行RDB 文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

AOF

RDB 存储的弊端

• 存储数据量较大，效率低
  • 基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低
• 大数据量的IO 性能较低
• 基于fork 创建子进程，内存产生额外消耗
• 宕机带来的数据丢失风险

解决思路

• 不写全数据，仅记录部分数据
• 改记录数据为记录操作过程
• 对所有操作均进行记录，排除丢失数据的风险

AOF 概念

• AOF（Append Only File） 持久化：以独立日志的方式记录每次写命令，重启时在重新执行AOF 文件中命令，达到恢复数据的目的。与RDB 相比可以简单描述为改记录数据为记录数据产生的过程
• AOF 的主要作用是解决了数据持久化的实时性，目前已经是Redis 持久化的主流方式

AOF 写数据过程

 注意：问号部分指的是——这些缓存的写命令写入.aof文件的时机和写入.aof的数量？

            处理这个问题的方法是AOF 写数据的三种策略！

AOF 写数据的三种策略

• always（每次）：每次写入操作均同步到AOF 文件中，数据零失误，性能较低
• everysec（每秒）：每秒将缓冲区中的指令同步到AOF中，数据准确性高，性能较高。在系统突然宕机的情况下丢失1s内的数据
• no（系统控制）：有操作系统控制每次同步到AOF 文件的周期，整体过程不可控

AOF 功能开启

• 配置：appendonly yes|no
• 作用：是否开启AOF 持久化功能，默认为不开启状态
• 配置：appendfsync always|everysec|no
• 作用：AOF 写数据策略
• 配置：appendfilename filename
• 作用：AOF 持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof
• 配置：dir
• 作用：AOF 持久化文件保存路径，与RDB 持久化文件保持一致即可。

AOF 写数据遇到的问题

• 如果连续执行如下指令该如何处理

        问题描述：连续指令是对同一个数据进行操作且仅最后一个指令是最后的数据结果，

                          如何对其进行优化？

        问题解决：AOF 重写机制

AOF 重写机制

主要作用是对.aof文件进行体积压缩，从而解决.aof 文件过大的问题。

• AOF 重写机制的原理：将redis 进程内的数据转化为写命令同步到新 AOF 文件的过程。
• AOF 重写机制的作用：

1. 降低磁盘占用量，提高磁盘利用率
2. 提高持久化效率，降低持久化写时间，提高IO性能
3. 降低数据恢复用时，提高数据恢复效率

• AOF 重写规则：

1. 进程内已超时的数据不再写入文件
2. 忽略无效指令，重写时使用进程内数据直接生成
   1. 注意：该条就是解决上述问题的关键    如：del key1、set key2 a, set key2 b
3. 对同一数据的多条写命令合并为一条命令
   1. lpush list1 a，lpush list1 b => lpush list1 a b

• AOF 重写方式：
  • 手动重写：bgrewriteaof，原理如下：
  • 
  • 自动重写:
    • auto-aof-rewrite-min size size
    • auto-aof-rewrite-percentage percentage
    • 原理
      • 

AOF 工作流程

 

 RDB 与 AOF 区别

RDB vs AOF 

 RDB 与 AOF 的选择之惑

 持久化应用场景

• 第一种应用场景tips1：不适合做持久化
• 第三种应用场景tips3：不适合做持久化
• 第四种应用场景tips4：不适合做持久化
• 第五种应用场景tips5：可以使用持久化
• 第六种应用场景tips6：可以使用持久化
• 第七种应用场景tips7：可以使用持久化
• 第九种应用场景tips9：不适合做持久化
• 第十二种应用场景tips12：黑名单不做持久化，白名单做持久化
• 第十三种应用场景tips13：可以使用持久化
• 第十五种应用场景tips15：不适合做持久化（实际开发中一般不会使用redis作为消息队列）
• 第十六种应用场景tips16：不适合做持久化