【自撰】Redis快照 RDB、AOF

Redis有两种持久化策略

• RDB（RedisDataBase）是redis默认的持久化机制
• AOF（Append Only File）

RDB配置

在redis.conf文件中，设置快照(SNAPSHOTTING)的配置。

• save 900 1 每900秒至少有一个key发生变化，则dump内存快照

• save 300 10 每300秒至少有10个key发生变化，则dump内存快照

• save 60 10000 每60秒至少有10000个key发生变化，则dump内存快照
  
  上述配置已是最优的配置，不建议修改。

触发RDB快照

• 关redis服务器时，会快照一次

./bin/redis-cli shutdown

flushall 清空所有数据库中的缓存后，也会快照一次。

flushall

rdb的恢复

第一种方式：

• 如果一不小执行了flushall命令之后，将备份的dump_bak文件覆盖安装目录下的原始的dump 文件，并启动服务即可。
  
• 在redis.conf文件中有如下配置

  # The filename where to dump the DB
  dbfilename dump.rdb

• config get 命令用于取得运行中的 Redis 服务器的配置参数，使用命令 CONFIG GET * ，可以列出 CONFIG GET 命令支持的所有参数。

• config get dir可以获取快照文件(dump.rdb)的存储路径，config get dbfilename可以获取快照文件的文件名。

第二种方式：

• 执行命令save ，将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。save命令是同步进行的，也就是save时只管保存，其它的都不管，全部阻塞。
• 执行命令bgsave，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。
• 生产环境不要执行SAVE命令，因为这会阻塞所有的客户端。通常可以使用BGSAVE代替。

RDB的优缺点

• 优点：
  • 快照保存大规模数据和还原大规模数据的速度极快。
  • 对数据完整性和一致性要求不高。
  • 适用于灾难备份。出紧急事故时，可以快速地将dump.rdb文件备份。
• 缺点：
  • 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。
  • Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑(进程复制，数据也复制了，只快照克隆的数据)。如果数据量大，内存容量又较小，那么很有可能会导致系统崩掉。所以，小内存机器不适合使用。

AOF配置

• appendonly no 改为 yes

  • 改为yes表示打开AOF机制。
  • redis 同步数据文件是按上面save条件来同步的，如果发生诸如拉闸限电、拔插头等状况，那么将造成比较大范围的数据丢失，所以redis提供了另外一种数据库备份的方式。开启appendonly 模式后，redis 将每一次写操作请求都追加到appendonly.aof 文件中，redis重新启动时，会从该文件恢复出之前的状态。
  • appendonly.aof的创建时机：将redis_aof.conf文件中的appendonly 改为yes后，第一次启动redis服务器时，就会在/usr/local/redis/5.0.8目录下创建appendonly.aof文件。

• appendfilename appendonly.aof

  记录日志的文件名，默认值为appendonly.aof。也就是将写指令记录到appendonly.aof文件。

• appendfsync everysec （用默认值，不改）

  Redis在处理一条命令时，并不立即调用write写AOF文件，只是将数据写入到AOF buffer（server.aof_buf）中，也就是AOF缓冲池。在进行fsync()调用时，再将缓冲池中的数据写入磁盘，也就是写入AOF文件。

  设置更新日志条件，共有3个可选值：

  • no：表示等操作系统进行数据缓存时同步到磁盘（性能快，数据不安全）

    当设置appendfsync为no的时候，Redis不会主动调用fsync去将AOF日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次fsync()调用，将缓冲区中的数据写到磁盘上。

  • always：表示每次更新操作后自动调用fsync()将数据写到磁盘（性能慢，数据安全）

    当设置appendfsync为always时，每一次写操作都会调用一次fsync，这时数据是最安全的，当然，由于每次都会执行fsync，所以其性能也会受到影响。

  • everysec：每隔一秒进行一次fsync()调用，将缓冲区中的数据写到磁盘（性能和安全性折中，默认值）

    当设置appendfsync为everysec的时候，Redis会默认每隔一秒进行一次fsync调用，将缓冲区中的数据写到磁盘。但是当这一 次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略，再等一秒钟。也就是在两秒后再进行fsync，这一次的fsync就不管会执行多长时间都会进行。

参考：
https://www.cnblogs.com/aquester/p/10080991.html
https://www.cnblogs.com/siqi/p/4245821.html

AOF启动/修复/恢复

• 正常恢复

  • 1、将redis_aof.conf文件中的appendonly 改为yes后，第一次启动redis服务器时，就会在redis的安装目录下创建一个appendonly.aof文件。
  • 2、用客户端连接此redis服务器，设置3个键值对。
  • 3、在启动redis服务器的shell窗口中，将appendonly.aof备份一份，备份文件名为appendonly_bak.aof。
  • 4、在客户端flushall后，执行shutdown命令，关闭redis服务器。
  • 5、在启动redis服务器的shell窗口中，将appendonly_bak.aof覆盖appendonly.aof文件。与此同时，将dump.rdb删除(排除快照文件的影响)。
  • 6、启动redis服务器，用客户端连接此redis服务器，又看到了之前被清空的键值对。说明redis服务器启动时，会读取appendonly.aof文件进行恢复数据。

• 异常恢复

  • 破坏appendonly.aof文件，在文件末尾随意添加几行文字。

  • 启动redis服务器，并查看redis进程，发现并没有查到。说明启动失败。

    ./bin/redis-server ./redis_aof.conf
    ps -ef | grep -i redis
    

  • 使用Redis-check-aof --fix命令 进行修复文件

    ./bin/redis-check-aof --fix appendonly.aof
    

• 修复完appendonly.aof文件后，再用vi命令查看文件，发现之前随意添加几行文字已被删除。

• 启动redis服务器，并查看redis进程，能查到刚启动的redis进程，启动成功。

重写配置

• no-appendfsync-on-rewrite 默认值为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。设置为yes，可能会丢失少量数据，但性能要好点。

  • 同时在进行rewrite操作和主进程写aof文件的操作，两者都会操作磁盘，而rewrite往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形，可以设置no-appendfsync-on-rewrite参数来避免阻塞。

    • 如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。

      在rewrite期间，会调用fsync()。

    • 如果设置为yes(在rewrite期间，不会调用fsync())。说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘）。

      如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢？在linux的操作系统的默认设置下，最多会丢失30s的数据。

    • 因此，如果应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no。

    https://blog.csdn.net/jingkyks/article/details/46956905

Rewrite触发机制

• 默认情况下，Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

AOF优缺点

• 优点：

  • 每次修改同步：appendfsync always 同步持久化每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好

  • 每秒同步：appendfsync everysec 异步操作，每秒记录，如果一秒内宕机，有数据丢失

  • 不同步：appendfsync no 从不同步

• 缺点：

  • 针对相同数据集的数据而言，aof文件要远大于rdb文件，恢复速度慢于rdb

  • aof运行效率要慢于rdb,每秒同步策略效率较好，不同步的效率和rdb相同

RDB与AOF对比

• RDB持久化方式 能够在指定的时间间隔内对你的数据进行快照存储。(默认开启)
• AOF持久化方式 记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据, AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写, 使得AOF文件的体积不至于过大。(默认关闭)
  • 一般开启rdb持久化就差不多了。原因：redis缓存服务器不会经常关，即使要关，也会正常关闭。而正常关闭时，会进行一次快照，所以不会有数据丢失。若有突然断电情况，大公司一般也会有备用电源。当主电源停电时自动切换到备用电源。
• **只做缓存：**如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。

同时开启两种持久化方式

• 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下，AOF文件保存的数据集要比RDB文件保存的数据集要完整。(aof保存的是指令，rdb仅一份快照)
• RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，RDB能快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

性能建议

• 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

• 如果Enable AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO(因为一直写aof文件)，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的(写新文件时也会竟争磁盘)。只要硬盘许可(硬盘足够大时)，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设置到5G以上。默认超过原大小100%时重写可以改到适当的数值。

• 如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构。