乐趣区

关于redis:redis-持久化

jiezi

咱们晓得 redis 很快是因为都是纯内存操作的，那如果数据仅仅在内存中，redis 宕机了数据是不是就没了，此时大量的申请在 redis 中找不到缓存的数据，就会间接申请数据库，导致数据库挂掉。所以 redis 提供了 RDB 和 AOF 两种不同的长久化办法把数据存储到硬盘中。RDB 是以快照的模式，将某一时刻的数据都写入到硬盘。AOF(append-only file) 是将每条执行的命令保留在硬盘，复原的时候，能够从文件里读取命令在 redis 里从新执行，达到复原的成果。这两种形式能够独自应用，也能够一起应用，取决于咱们的理论利用场景需要。

RDB

在 RDB 中长久化的触发有两种：主动触发和手动触发。

手动触发

手动触发有 save 和 bgsave 命令。
当 redis 接管到 save 命令时，就会创立快照，并且在快照创立结束之前，不会响应其余的命令。
当 redis 接管到 bgsave 命令时，redos 会 fork 一个子过程来创立快照，而后父过程会持续解决其余的命令。尽管不会阻塞其余命令，然而创立子过程会导致 redis 进展，并且因为子过程会争抢资源，导致创立快照的速度会比 save 慢。

主动触发

save 配置如下：代表在 N 秒内，如果有了 M 次的变动，则触发 bgsave 命令，如果配置了多个，则任意一个失效都触发 bgsave 命令。

save <seconds> <changes>

redis 默认的配置如下：

#900 秒内有 1 次变动则创立快照
save 900 1
#300 秒内有 10 次变动则创立快照
save 300 10
#60 秒内有 10000 次变动则创立快照
save 60 10000

除了下面的规定被触发会执行 bgsave 外，redis 接管到 shutdown 命令或者服务器敞开申请，又或者收到规范 TERM 信号时，会执行 save 命令，此时客户端的所有的申请将被阻塞，不在执行，并且在 save 命令执行完后敞开服务器。
redis 的其余对于 RDB 配置 

# bgsava 失败后是否进行接收数据
stop-writes-on-bgsave-error yes
# 是否对快照进行压缩
rdbcompression yes
# 快照文件名
dbfilename dump.rdb

优缺点

长处：

  1. 因为是快照模式，所以实用于全量备份。
  2. 复原速度快与 AOF。

毛病：

  1. 无奈实时创立快照，有可能造成局部数据失落。
  2. 通过子过程创立快照时，如果数据文件太大，有可能导致 redis 短暂进行服务。

AOF

AOF 会将 redis 执行过的命令追加到文件的开端，也就是说如果从文件的结尾开始执行到最初，就会失去之前一样的数据。redis 默认是没有开启 AOF 的，须要 appendonly 设置为 yes 才开启。
除了 appendonly 配置，还有其余配置：

# 默认 AOF 文件名
appendfilename "appendonly.aof"
# 每个命令都要追加到文件，性能绝对差
# appendfsync always
# 每秒同步，最多会失落一秒的数据
appendfsync everysec
# 让操作系统决定何时同步，不可控，不举荐
# appendfsync no

因为 AOF 须要始终的写文件，会导致文件会始终增长，redis 提供了 AOF 文件压缩的命令，BGREWRITEAOF。相似于 bgsave，BGREWRITEAOF 也会 fork 一个子过程，对 AOF 文件进行重写，所以一样会有因为创立子进行导致的资源争抢和内存占用的问题。对于重写，有以下配置：

# 比上一次重写后的体积大于 100% 并且大于 64m 的时候重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

优缺点

长处：

  1. 最多失落一秒的数据。
  2. 把命令追加到文件开端，没有任何磁盘寻址的开销，写入的速度十分快。

毛病：

  1. 文件大，复原速度慢。
  2. 绝对于 RDB，因为每秒须要追加日志，反对的写 QPS 较低。

复原

需复原的时候，只有把 RDB 或者 AOF 文件放在配置的门路上面，重启 redis 服务器就能够复原。如果同时存在两种长久化形式，并且有 AOF 文件，就会从 AOF 文件复原数据，否则从 RDB 文件复原数据。

退出移动版