Redis 实战 —— 06. 持久化选项

持久化选项简介 `P61`

Redis 提供了两种不同的持久化方法来将数据存储到硬盘里面。

RDB(redis database)：可以将某一时刻的所有数据都写入硬盘里面。（保存的是数据本身）
AOF(append only file)：会在执行命令时，将被执行的写命令复制到硬盘里面。（保存的是数据的变更记录）

两种持久化方法既可以同时使用，又可以单独使用，在某些情况下甚至可以两种方法都不使用，具体选择哪种持久化方法需要根据数据以及应用来决定。

快照持久化 `P62`

配置选项

# 持久化触发条件：seconds 秒内至少有 changes 个键被更改

# save <seconds> <changes>

#

# 默认配置以下三个触发持久化的条件

# 【注】注释掉所有 save 的配置，就不会开启快照持久化

#

# 900 秒(15 分钟)内至少有 1 个键被更改

# 300 秒（5 分钟）内至少有 10 个键被更改

# 60 秒（1 分钟）内至少有 10000 个键被更改

save 900 1

save 300 10

save 60 10000

# 如果快照持久化开启

# yes：后台持久化操作失败时，Redis 就会停止接受更新操作（默认 yes）

# no ：后台持久化操作失败时，Redis 仍然可以继续正常工作

stop-writes-on-bgsave-error yes

# 在进行镜像备份时，是否进行压缩

# yes：压缩，会有更多 cpu 消耗，时间会更长（默认 yes）

# no ：不压缩，需要更多磁盘空间

rdbcompression yes

# 数据库文件的文件名

dbfilename dump.rdb

# 工作目录，数据库文件的位置

# AOF（append only file）也会在此目录创建

dir ./

如果新的快照文件创建完成之前，Redis 、系统或者硬件这三者之中的任意一个崩溃了，那么 Redis 将丢失最近一次成功创建快照之后写入的所有数据。快照持久化只适用于那些即使丢失一部分数据也不会造成问题的程序，而不接受数据损失的程序可以考虑使用 AOF 持久化。 P63

创建快照的方法 `P63`

客户端可以通过向 Redis 发送 BGSAVE 命令来主动创建快照。对于支持 BGSAVE 命令的平台（除了 Windows 平台）来说，由 fork 创建出的子进程负责将快照写入硬盘，父进程继续处理命令请求。
客户端可以通过向 Redis 发送 SAVE 命令来主动创建快照，接到 SAVE 命令的 Redis 服务器在快照创建完毕之前不会响应任何命令。
设置了 save 配置选项，那么当任意一个条件满足时， Redis 就会自动触发一次 BGSAVE 命令。
当 Redis 通过 SHUTDOWN 命令接收到关闭服务器的请求时，或者接收到标准 TERM 信号时，会执行一个 SAVE 命令，阻塞所有客户端，不再执行客户端发送的任何命令，并在 SAVE 命令执行完毕之后关闭服务器。
当一个 Redis 服务器连接另一个 Redis 服务器，并向对方发送 SYNC 命令来开始一次复制操作的时候，如果主服务器目前没有在执行 BGSAVE 操作，或者并非刚刚执行完 BGSAVE 操作，那么主服务器就会执行 BGSAVE 命令。

the master Redis server will start a BGSAVE operation if one isn’t already executing or recently completed.

斜体加粗的部分感觉有点难理解，第二个就已经包含在第一个条件里了，然后找到英文原文还有点懵。

不同场景下的使用 `P64`

个人开发：主要考虑尽可能地降低快照持久化带来的资源消耗，只设置 save 900 1 这一条规则。 P64
对日志进行聚合计算：主要考虑 Redis 因为崩溃而未能成功创建新的快照，那么我们能承受丢失多长时间以内产生的新数据。还需要设计如何恢复被中断的聚合计算，可以记录每次处理的日志文件名及偏移量，恢复时按升序从记录处开始处理。 P64
大数据：当 Redis 存储的出具了达到即使 GB 时，执行 BGSAVE 可能会导致系统长时间地停顿，也可能引发系统大量地使用虚拟内存，从而导致 Redis 的性能降低至无法使用的程度。可以考虑手动发送 BGSAVE 或者 SAVE 来进行持久化，避免自动执行而造成停顿。P65

RDB 的优点

非常紧凑
适合用于灾难恢复
可以最大化 Redis 的性能
恢复大数据集时的速度比 AOF 的恢复速度要快

RDB 的缺点

宕机时丢失数据可能较多
每次持久化时都要 fork() 一个子进程，当数据集比较庞大时可能非常耗时

AOF 持久化 `P66`

配置选项

# AOF 持久化是否开启

# yes：开启 AOF 持久化，Redis 在启动时会载入 AOF，而忽略快照持久化文件

# no ：不开启 AOF 持久化（默认不开启）

appendonly no

# AOF 文件名（默认为 appendonly.aof）

appendfilename "appendonly.aof"

# Redis 支持三种不同的回写模式

# always  ：每次写操作都调用 fsync()，立刻写入 AOF 文件。非常慢但是很安全。

# everysec：每秒调用一次 fsync()。折衷方案。（默认为 everysec）

# no	  ：不调用 fsync()，等待操作系统刷数据。很快。

# appendfsync always

appendfsync everysec

# appendfsync no

# 如果有延迟问题就将该选项设置为 yes

# 否则就保持 no，这是最安全的方式

no-appendfsync-on-rewrite no

# 自动重写 AOF 文件，若百分比设置为 0，则表示禁用自动重写 AOF 文件

# 如果当前 AOF 文件大小以及比上次 AOF 文件大小大了 指定的百分比，则会重写 AOF 文件

# 同时需要指定 AOF 文件重写的最小大小，以避免百分比过小而频繁重写 AOF 文件

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

重写 AOF 文件 `P67`

Redis 会不断地将被执行的写命令记录到 AOF 文件里面，AOF 文件会不断增大，可能会用完硬盘的所有可用空间，重启之后还原操作也可能执行很长时间。 P68

为了解决 AOF 文件不断增大的问题，用户可以向 Redis 发送 BGREWRITEAOF 命令，这个命令会通过移除 AOF 文件中冗余命令来重写 AOF 文件，使 AOF 文件变得尽可能地小。BGREWRITEAOF 的工作原理和 BGSAVE 创建快照的工作原理非常相似： Redis 会创建一个子进程，然后由子进程负责对 AOF 文件进行重写。P68

重写 AOF 文件是从数据集中读取键当前的值，然后用一条命令取记录键值对，代替之前记录该键值对的多个命令，最终生产一个新的 AOF 文件，这个文件包含重建当前数据集所需的最少命令。

AOF 的优点

AOF 文件只追加，所以写入时不需要进行 seek
AOF 文件过大时，后台会自动对 AOF 文件进行重写
有序地保存了数据库执行的所有写入操作，易读懂，也能轻松分析文件

AOF 缺点

相同数据集时，AOF 文件的体积通常大于 RDB 文件的体积
根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB
个别命令（例如：BRPOPLPUSH source destination timeout）会导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样

本文首发于公众号：满赋诸机（点击查看原文）开源在 GitHub ：reading-notes/redis-in-action