Redis持久化策略

        Redis 是内存数据库，它将数据存储在内存中以提供高性能和低延迟的读写操作。然而，由于数据存储在内存中，一旦 Redis 服务器关闭或崩溃，内存中的数据将会丢失。为了解决这个问题，Redis 提供了持久化功能，可以将数据保存到磁盘上，以便在服务器重启后可以恢复数据。Redis有两种持久化策略，分别是RDB（Redis Database）和AOF（Append-Only File）。

        rdb和aof的存在意义是保证在发生意外情况时可以从持久化的文件中恢复在内存中丢失的数据。

RDB

        Redis会单独创建一个（fork）子进程来进行持久化，这个子进程是调用操作系统的fork函数来实现的，会先将数据写入到一个临时文件中，待持久化进程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何io操作的。这保证了极高的新能。如果需要进行大规模的数据恢复，且对于恢复的完整性不敏感，那RDB的方式要比AOF方式更加的有效。RDB的缺点是最后一次持久化的数据可能丢失。默认情况下是RDB。

 RDB的触发条件

1.save规则满足的情况下，会自动触发RDB规则。

我们可以在配置文件中看到，默认情况下当900秒1次、300秒10次和60秒10000次的情况下，会触发RDB机制并将数据写入dump.rdb文件中。

save 900 1
save 300 10
save 60 10000

2.执行flushall命令

3.退出redis

恢复数据

只需要将rdb文件放在redis的启动目录中就可以，redis启动的时候会自动检查dump.rdb并恢复其中的数据。 

优点

适合大规模的数据恢复；

对数据完整性和一致性要求不高

缺点

在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

fork进程会占用一定的内存空间。

AOF

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。写入的文件名是appendonly.aof。

AOF采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时， Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.。

默认情况下AOF是不开启的，我们需要进行手动配置

appendonly yes

如果appendonly.aof内容被修改出现了异常，此时redis是无法启动的，我们需要使用redis提供的命令

redis-chech-aof  --fix

对文件进行修复。

优点

1.每一次修改都会进行同步，文件的完整新更好。

2.每秒同步一次，只会丢失一秒的数据。

缺点

1.相对于rdb，aof的文件更大，恢复速度也更慢。

2.运行效率相比于rdb更慢。