Redis 数据持久化

上一篇文章（ 地址）

1、数据持久化的介绍

Redis 持久化

• Redis 的读写都是在内存中，性能较高
• 但在内存中的数据会随着服务器的重启而丢失
• 为了保证数据不丢失，我们需要将内存中的数据存储到磁盘
• 以便 Redis 重启时能够从磁盘中恢复原有的数据

持久化的几种方式

• 快照方式（RDB，Redis DataBase）将某一个时刻的内存数据，以二进制的方式写入磁盘
• 文件追加方式（AOF，Append Only File），记录所有的操作命令，并以文本的形式追加到文件中
• 混合持久化方式，Redis 4.0 之后新增的方式，混合持久化是结合了 RDB 和 AOF 的优点，在写入的时候，先把当前的数据以 RDB 的形式写入文件的开头，再将后续的操作命令以 AOF 的格式存入文件，这样既能保证 Redis 重启时的速度，又能减低数据丢失的风险

2、开启持久化

2.1、Redis 持久化 — RDB

RDB

• RDB简介：RDB（Redis DataBase）是将某一个时刻的内存快照（Snapshot），以二进制的方式写入磁盘的过程
• RDB 的持久化触发方式有两类：一类是手动触发，另一类是自动触发

2.1.1、手动持久化方式

手动触发

• 手动触发持久化的操作有两个： save 和 bgsave
• 它们主要区别体现在：是否阻塞 Redis 主线程的执行

save 命令

• 在客户端中执行 save 命令，就会触发 Redis 的持久化
• 但同时也是使 Redis 处于阻塞状态，直到 RDB 持久化完成，才会响应其他客户端发来的命令

bgsave 命令

• bgsave（background save）后台保存
• 它和 save 命令最大的区别就是 bgsave 会 fork() 一个子进程来执行持久化
• 整个过程中只有在 fork() 子进程时有短暂的阻塞，当子进程被创建之后，Redis 的主进程就可以响应其他客户端的请求

2.1.2、自动持久化方式

自动触发

• save m n 是指在 m 秒内，如果有 n 个键发生改变，则自动触发
• 持久化参数 m 和 n 可以在 Redis 的配置文件中找到
• 例如，save 60 1 则表明在 60 秒内，至少有一个键发生改变，就会触发 RDB 持久化
• 自动触发持久化，本质是 Redis 通过判断，如果满足设置的触发条件，自动执行一次 bgsave 命令
• 注意：当设置多个 save m n 命令时，满足任意一个条件都会触发持久化
• flushall 命令用于清空 Redis 数据库，在生产环境下一定慎用，当 Redis 执行了 flushall 命令之后，则会触发自动持久化，把 RDB 文件清空

vim redis.conf

• rdbcompression 参数
• 默认值是 yes 表示开启 RDB 文件压缩，Redis 会采用 LZF 算法进行压缩，如果不想消耗 CPU 性能来进行文件压缩的话，可以设置为关闭此功能，这样的缺点是需要更多的磁盘空间来保存文件
• rdbchecksum 参数
• 默认值为 yes 表示写入文件和读取文件时是否开启 RDB 文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动

2.1.3、RDB 优缺点

RDB 优点

• RDB 的内容为二进制的数据，占用内存更小，更紧凑，更适合做为备份文件
• RDB 对灾难恢复非常有用，它是一个紧凑的文件，可以更快的传输到远程服务器进行 Redis 服务恢复
• RDB 可以更大程度的提高 Redis 的运行速度，因为每次持久化时 Redis 主进程都会 fork() 一个子进程，进行数据持久化到磁盘，Redis 主进程并不会执行磁盘 I/O 等操作
• 与 AOF 格式的文件相比，RDB 文件可以更快的重启

RDB 缺点

• 因为 RDB 只能保存某个时间间隔的数据，如果中途 Redis 服务被意外终止了，则会丢失一段时间内的 Redis 数据
• RDB 需要经常 fork() 才能使用子进程将其持久化在磁盘上，如果数据集很大，fork() 可能很耗时，并且如果数据集很大且 CPU 性能不佳，则可能导致 Redis 停止为客户端服务几毫秒甚至一秒钟

2.2、Redis 持久化 — AOF

AOF 持久化

• AOF（Append Only File）中文是附加到文件，顾名思义 AOF 可以把 Redis 每个键值对操作都记录到文件（appendonly.aof）中

2.2.1、持久化查询和设置

查询 AOF 启动状态

• config get appendonly

开启 AOF 持久化

• 通过命令行的方式
• 通过修改配置文件的方式（redis.conf）

2.2.2、命令行启动 AOF

• 第一步：config set appendonly yes
• 第二步：config get appendonly

2.2.3、配置文件启动 AOF

• 第一步：config get dir（查看配置文件目录）
• 第二步：vim root/redis-6.2.1/redis.conf （文件编辑器进入此配置文件）

• 第三步：将 appendonly no 修改为 appendonly yes

配置文件启动 AOF 的优缺点：

• 缺点是每次修改配置文件都要重启 Redis 服务才能生效
• 优点是无论重启多少次 Redis 服务，配置文件中设置的配置信息都不会失效

3、触发持久化

AOF 的触发条件分为两种：自动触发和手动触发

3.1、自动触发

自动触发

• 触发 AOF 持久化分二种情况：满足 AOF 设置的策略触发和满足 AOF 重写触发

AOF 持久化策略，分为以下三种：

• always：每条 Redis 操作命令都会写入磁盘，最多丢失一条数据
• everysec：每秒钟写入一次磁盘，最多丢失一秒的数据
• no：不设置写入磁盘的规则，根据当前操作系统来决定何时写入磁盘，Linux 默认 30s 写入一次数据至磁盘

AOF 文件重写

• AOF 是通过记录 Redis 的执行命令来持久化（保存）数据的，所以随着时间的流逝 AOF 文件会越来越多，这样不仅增加了服务器的存储压力，也会造成 Redis 重启速度变慢，为了解决这个问题 Redis 提供了 AOF 重写的功能

3.2、手动触发

在客户端执行 bgrewriteaof 命令就可以手动触发 AOF 持久化

4、AOF 文件重写

AOF 文件重写

• AOF 重写指的是它会直接读取 Redis 服务器当前的状态，并压缩保存为 AOF 文件
• 例如，我们增加了一个计数器，并对它做了 99 次修改，如果不做 AOF 重写的话，那么持久化文件中就会有 100 条记录执行命令的信息，而 AOF 重写之后，之后记录一条此计数器最终的结果信息，这样就去除了所有的无效信息

AOF 重写实现（两个条件）

• auto-aof-rewrite-min-size：允许 AOF 重写的最小文件容量，默认是 64mb
• auto-aof-rewrite-percentage：AOF 文件重写的大小比例，默认值是 100，表示 100%，也就是只有当前 AOF 文件，比最后一次（上次）的 AOF 文件大一倍时，才会启动 AOF 文件重写

AOF 重写流程

• AOF 文件重写是生成一个全新的文件，并把当前数据的最少操作命令保存到新文件上，当把所有的数据都保存至新文件之后，Redis 会交换两个文件，并把最新的持久化操作命令追加到新文件上