redis的持久化

忘是亡心i 2021-12-24 10:23 235阅读 0赞

首先,redis的持久化操作分

*  RDB
 *  AOF
 *  RDB和AOF混合的模式

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储.

而AOF则是redis的操作日志都记录下来。

如果rdb和aof都存在的话，默认启动加载的是aof配置文件下的数据，因为aof保存的数据比rdb快照的更加完整。

rdb保存的时间点，在redis.conf下里的 sava xxx xxx，分两个一个时间间隔和数据量，当数据量满足时，就会保存一份rdb快照。

同时，redis意外宕机,你可能会丢失几分钟的数据。所以不能保证数据完整性。

使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.

aof文件有序的保存了对redis写入的操作，方便重写。

由于aof的fsync策略，导致速度比rdb慢，一般情况下，aof的性能还是比较高的，同时，关闭了fsync可以让速度达到rdb一样快的。不过，在巨大的写入和载入的过程中，rdb可以保证最大时延。

为了保证安全性，应该使用2种混合模式。

**使用快照**

通过在配置文件里改动

save 60 1000

60s内数据数据量达到1000进行一次快照，通过调整上述的参数来自定义配置。

## 只追加操作的文件（Append-only file，AOF） ##

想开启aof功能，只要在配置文件中

appendonly yes

从现在开始， 每当 Redis 执行一个改变数据集的命令时（比如 SET）， 这个命令就会被追加到 AOF 文件的末尾。这样的话， 当 Redis 重新启时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。

**日志重写功能**

aof功能就是对操作写入文件中，方便重写，如果进行1000incr操作，那么日志文件就有1000条incr操作记录，这是浪费占用空间的，于是redis2.4可以自动触发redis重写，减少日志文件的体积。

**aof的fsync设置的策略**

*  每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全
 *  每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。
 *  从不 fsync ：将数据交给操作系统来处理。更快，也更不安全的选择。
 *  推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

**如果redis服务器突然停机，对aof文件造成的损坏怎么办？**

*  为现有的 AOF 文件创建一个备份。
 *  使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复:
    
    $ redis-check-aof –fix
 *  （可选）使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处。
 *  重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。

**怎么样从rdb切换到aof文件？**

*  为最新的 dump.rdb 文件创建一个备份。
 *  将备份放到一个安全的地方。
 *  执行以下两条命令:
 *  redis-cli config set appendonly yes //redis不重启的情况下，开启aof日志功能
 *  redis-cli config set save “” //关闭rdb功能
 *  确保写命令会被正确地追加到 AOF 文件的末尾。

注意：上述只是在redis配置中改变，如果redis重启还是从用以前的配置，所以，需要在配置文件开启aof即 appendonly yes 不被注释 。