共计 2694 个字符，预计需要花费 7 分钟才能阅读完成。
Redis 有两种长久化计划，RDB（Redis DataBase）和 AOF（Append Only File）
一、RDB
redis 的 RDB 计划是一种快照形式长久化，就是在某时刻把所有数据进行残缺备份。RDB 是 redis 默认的长久化计划，它的作用是一旦在指定的工夫距离内，执行指定次数的写操作，redis 服务会将内存中的数据写入磁盘中，默认是写入 /var/lib/redis/dump.rdb 文件，redis 重启会通过加载 dump.rdb 文件复原数据
1. 从配置文件理解 RDB
关上 /etc/redis.conf 文件，找到 SNAPSHOTTING 局部内容
1. ################################ SNAPSHOTTING ################################
2. # save <seconds> <changes>
3. # 上面第一行的意思是如果 900 内至多有一个键被改变，主动进行数据保留，若不想应用 RDB 长久化能够把所有
4. #save 配置正文掉，或者增加一行 save ""
5. save 900 1
6. save 300 10
7. save 60 10000
9. # 若 redis 最近一次长久化到 dump 文件出错，则默认不容许进行写操作，改成 no 则忽视长久化谬误容许写操作
10. stop-writes-on-bgsave-error yes
12. # 压缩 dump 长久化文件，改成 no 不压缩文件会变大很多，不过能节一点 cpu，倡议应用默认值 yes
13. rdbcompression yes
15. #长久化文件校验，会耗费一些性能，倡议应用默认值 yes
16. rdbchecksum yes
18. # RDB 长久化文件名
19. dbfilename dump.rdb
21. # 长久化文件存储目录，即 dump 文件所在目录，aof 文件也会放在这个目录下
22. dir /var/lib/redis 2. 触发 RDB 快照的几种形式
save 此命令是同步命令，在长久化时会阻塞所有客户端申请
bgsave 异步命令，会生成一个子过程将内存数据保留到 dump 文件，不影响主过程服务。通过配置文件 save 属性触发的长久化也是通过 bgsave 形式保留，新建过程会耗费内存
flushall 此命令在清空 redis 数据后会进行长久化操作
shutdown 应用 shutdown 命令会先进行长久化操作再敞开服务
3. 优缺点
长处：
紧凑的繁多文件，实用于劫难复原
与 aof 相比，在复原大的数据集时，RDB 形式会更快
毛病：
RDB 须要常常生成子过程来进行数据长久化，耗时、耗性能
数据完整性不高，依据配置，一旦产生 redis 意外宕机可能会失落几分钟的数据
二、aof
redis 的 aof 备份是一种写日志形式长久化，就是将用户所有的写指令备份到文件中，还原数据时会将所有指令从新执行一遍。redis 默认不开启 aof，redis 中 RDB 和 aof 两种长久化形式能同时应用
1.aof 重写
因为 aof 的运作形式是一直将命令追加至文件的开端，随着写入命令的一直减少，aof 文件体积会变得越来越大。比方，对一个计数器调用了 100 此 incr，那仅仅为了保留一个值 aof 文件就须要应用 100 条记录。这样不止会造成 aof 文件体积过大，还会导致数据恢复时速度太慢。而实际上只用一条 set 命令就足以保留计数器以后值了。
为了解决这种状况 redis 反对 bgrewriteaof 重写命令，用于异步执行 aof 文件重写操作，下面的 100 条记录变成 1 条。它会创立一个以后 aof 文件的优化版本，而即便 bgrewriteaof 执行失败，也不会有任何数据失落，因为旧的 aof 文件在 bgrewriteaof 胜利之前不会被批改。redis 在肯定条件下会自发进行重写，也能够调用 bgrewirteaof 命令被动重写
2. 从配置文件理解 aof
关上 /etc/redis.conf 文件，找到 APPEND ONLY FILE 局部
1. # 为了解决 RDB 一致性问题而生，默认不开启
2. appendonly no
4. #保留文件名
5. appendfilename "appendonly.aof"
7. # aof 实际上是调用 fsync()让零碎将内存中数据保留到磁盘上，有些零碎会立刻保留，有些零碎只能做到“尽可能快”保留
8. #redis 反对三种模式来调用 fsync():
9. #no: 不调用，零碎按本人步调保留内存数据到磁盘
10. #always：每一次写操作都调用
11. #everysec：每秒调用一次
12. # appendfsync always
13. appendfsync everysec
14. # appendfsync no
16. # aof 的 fsync 尽管是一个独自线程，然而它还是会阻塞 redis 的同步写操作，而 RDB 的 bgsave 和 aof 的 bgrewriteaof(重写，从前面理解）17. # 会占用大量的 I /O，是 fsync 阻塞住，那就意味着阻塞同步写操作。上面属性意思是不在 bgsave 或 bgrewriteaof 时
18. # 调用 async，如果填 yes 最坏状况有可能导致失落 30 秒的日志。为了数据一致性默认填 no
20. no-appendfsync-on-rewrite no
22. #上面两个用于配置主动重写的触发条件。只有两个条件都满足才触发
23. #第一个以后 aof 文件比上一次重写后 aof 文件减少的百分比，如果是 0 则 aof 不会主动重写，如果没有上一次
24. #重写则按 redis 服务启动时 aof 文件大小算
25. #第二个示意 aof 文件至多要达到这个大小才重写，次要为了避免 aof 文件很小的时候常常触发重写
26. auto-aof-rewrite-percentage 100
27. auto-aof-rewrite-min-size 64mb
29. # 在一些时候会产生 aof 文件最初面记录出问题，比方服务奔溃 aof 一行记录写到一半
30. #上面这个属性 yes 示意在复原数据时碰到最初一条问题记录会记录下来然而不影响后面数据恢复，no 则间接复原失败
31. aof-load-truncated yes
3. 优缺点
长处：
redis 更持久，应用默认的每秒 fsync 策略，能保障最多失落 1 秒的数据，而性能仍旧很好
有序的保留了对数据库的操作，易读。比方不小心执行 flushall 命令，找到 aof 文件，移除开端的 flushall 命令，就能复原数据
毛病
雷同数据集下，aof 文件体积通常要大于 RDB 文件体积
aof 的数据恢复速度可能会低于 RDB 不过是能够承受的