乐趣区

关于redis:Redis-实战-06-持久化选项

jiezi

长久化选项简介 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

退出移动版