Redis持久化策略——RDB、AOF、混合

一、RDB(redis database)

Redis默认启用该模式进行持久化，自动RDB使用的是异步方式（开启子进程）生成全量快照，配置文件为 redis.conf

①配置项：dbfilename #RDB文件名

②配置项：dir #RDB文件路径（默认为启动Redis服务时的当前目录）

③ 配置项：save #保存点(设置自动持久化的频率)

格式：save 可以设置多个save
900秒内Redis数据库有一条数据被修改则触发RDB
300秒内有10条数据被修改则触发RDB
60秒内有10000条数据被修改则触发RDB
注：如果同时使用RDB和AOF，则RDB的该配置仅保留save 900 1即可，RDB用作AOF数据文件的备用。

④禁用快照自动保存

方式1：注释掉所有的save配置；
方式2：在最后一条save配置后添加 save “”

⑤配置项： stop-writes-on bgsave-error

#Redis生成快照文件失败，则停止接收数据，目的让用户能知道到数据没有持久化成功(默认值为yes开启)

⑥配置项： rdbcompression

#Redis是否压缩RDB文件（压缩动作会消耗CPU资源） 默认yes压缩

⑦配置项： rdbchecksum

#Redis是否对对RDB数据进行校验（校验会消耗CPU资源） 默认yes校验

⑧手动生成快照（禁用快照功能并不影响手动生成快照）

  redis客户端使用命令SAVE：使用同步的方式生成RDB快照文件，将当前Redis实例的所有数据快照（Snap Shot）以RDB文件的形式保存到硬盘，默认情况下会把Redis数据持久化到dump.rdb文件中，并且在Redis服务器重启后自动读取dump.rdb文件。SAVE命令在Redis主线程中工作，会阻塞其他请求操作，实际生产中避免使用。

redis客户端使用命令BGSAVE：使用异步的方式保存当前Redis实例的所有数据快照RDB文件，执行BGSAVE命令后，Redis会产生一个子进程并立刻回复对客户端的服务。（推荐）

⑨ 数据修复：如宕机或不知原因的Redis进程终止，导致rdb文件损坏

Linux终端直接使用命令： redis-check-rdb filename.rdb

二、AOF(append on file)

配置项在配置文件： redis.conf 中

① 配置项： appendonly #启动AOF（默认为no不启动）

② 配置项： appendfilename #AOF文件名

③ 配置项： dir #文件路径与RDB文件共用同一目录，都是由dir指定

④ 配置项：appendfsync #可靠性配置，默认everysec

  always:
    每次收到Redis客户端的写命令就立即强制写入到AOF文件。这是最后保证的持久化方式，但也是速度最慢的，一般不推荐使用。
  everysec:
    每秒向AOF文件写入一次Redis客户端的写操作。在性能和持久化方面做了很好的折中（推荐）
  no:
    由操作系统来均订什么时候写入AOF文件，一般为30秒左右一次。这个方式性能最好，但持久化方面没有保证，一般不推荐。

⑤ 日志重写

  为了解决AOF文件随着操作不断增加，体积膨胀的问题，Redis提供了AOF重写功能：Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多，目前Redis由两个配置项控制日志重写机制:
  auto-aof-rewrite-percentage 100 #表示触发日志重写时，AOF文件比上一次重写后大了至少100%（Redis会记住上一次重写后AOF文件的大小）    注：auto-aof-rewrite-percentage 0 表示禁用日志重写
  auto-aof-rewrite-min-size 64MB #表示触发日志重写时，AOF文件的最小体积

注：虽然AOF会不断增加，但不会无限大，毕竟Redis只是作为缓存使用，而不是硬盘。

⑥ 数据损坏修复：因为某些原因（例如服务器崩溃）AOF文件损坏了，导致Redis加 载不了

Linux终端使用命令：redis-check-aof --fix
使用 diff -u *.aof *.rdb 查看文件是否有差异
修复AOF后重启Redis

⑦ RDB切换到AOF

在Redis2.2以后的版本中，从RDB切换到AOF，需要备份一个最新的dump.rdb文件，并把备份文件放在一个安全的地方
命令：
redis-cli config set appendonly yes
redis-cli config set save “”

三、rdb/aof数据文件备份频率(仅供参考)

①　写crontab 定时调度脚本，每小时copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48小时的备份
②　每天都保留一份当日的数据备份到一个目录中去，可以保留最近一个月的备份
③　每次copy备份的时候，都把太旧的备份给删了
④　每天晚上将当前机器上的备份复制一份到其他机器上，以防机器损坏

四、混合持久化及配置项（Redis4.0版本）

Redis 4.0 开始支持混合持久化（必须先开启AOF）
混合持久化优势：
  仅使用RDB快照方式恢复数据，由于快照时间粒度较大，时会丢失大量数据。
  仅使用AOF重放方式恢复数据，日志性能相对 rdb 来说要慢。在 Redis 实例很大的情况下，启动需要花费很长的时间。
  混合持久化解决了以上RDB和AOF的各自缺点，并结合各自优点将 rdb 文件的内容和增量的 AOF日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。
大量数据使用粗粒度（时间上）的rdb快照方式，性能高，恢复时间快
增量数据使用细粒度（时间上）的AOF日志方式，尽量保证数据的不丢失

① 配置项： aof-use-rdb-preamble #开启混合持久化 默认yes开启

五、集群中持久化的配置(推荐)

  Master使用AOF，Slave使用RDB快照，master需要首先确保数据完整性，它作为数据备份的第一选择；slave提供只读服务或仅作为备机，它的主要目的就是快速响应客户端read请求或灾备切换。

六、Redis过期key清除策略

1、被动清除：当读/写一个已经过期的key时，会触发惰性清除策略，直接清除这个过期key.
2、主动清除：由于惰性清除策略无法保证冷数据被及时清除，因此Redis会定期主动清除一批已过期的key.
3、当前已用内存超过maxmemory限定时，触发主动清除策略。
配置文件：redis.conf

① 配置项： maxmemory #最大内存空间，设置为0表示不限制

② 配置项： maxmemory-policy #当超过设置的maxmemory时，Redis进行数据淘汰的策略(默认noenviction)

术语：
  lru: least recently used 最近最少使用的（时间维度）
  lfu: least frequently user 最不经常使用的（频率维度）
▶ volatile-lru :从已设置过期时间的数据集中，挑选最近最少使用的数据淘汰
▶ allkeys-lru :从所有数据集中,挑选最近最少使用的数据淘汰
▶ volatile-lfu :从已设置过期时间的数据集中，挑选最不经常使用的数据淘汰
▶ allkeys-lfu :在键空间中，移除最不经常使用的key
▶ volatile-random :从已设置过期时间的数据集中,随机挑选数据淘汰
▶ allkeys-random :从所有的数据集中，随机挑选数据淘汰
▶ volatile-ttl :从已设置过期时间的数据集中,挑选即将过期的数据淘汰
▶ noenviction :禁止淘汰数据(只是在写操作上报错)

七、集群模式注意事项

▶ 在主从复制模式中：要确保master激活了持久化，并确保它不会在宕掉后自动重启。
因为slave是master的完整备份，因此如果master通过一个空数据集重启，slave也会被清掉（主从集群模式数据传递是单向的：主节点->从节点）。