redis的持久化

RDB和AOF

RDB
1.时点性存储
2.人为的触发保存的命令，save、bgsave，下面是两种命令的区别。
SAVE 直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。
BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成之后向主进程发送信号，通知保存已完成。 Redis 服务器在BGSAVE 执行期间仍然可以继续处理客户端的请求。
3.配置文件中也给出了bgsave的默认配置。
进入到redis目录中，可以看到两个配置，现在进入到6379中。

/SNAPSHOTTING可以快速查找到对应位置
下面各自对应了对应时间内，如果发生修改，就会触发save（其实是bgsave，并没有阻塞redis）操作
save 900 1 [900秒，有超过1个及以上的元素被修改，查询不算]
save 300 10 [300秒 ，有超过10个及以上的元素被修改，查询不算]
save 60 10000 [60秒，有超过10000个及以上的元素被修改，查询不算]

缺点：
1.时点与时点间的数据会发生丢失，例如8点记录了一次数据，9点之前如果几点出现问题，挂掉，那么9点这次需要保存的数据就会发生丢失。
2.不支持拉链，只有一个dump.rdb。
3.当redis中数据集比较大时候，RDB由于RDB方式需要对数据进行完成拷贝并生成快照文件，fork的子进程会耗CPU，并且数据越大，RDB快照生成会越耗时。
4.RDB文件是特定的格式，阅读性差，由于格式固定，可能存在不兼容情况。
优点：
1.类似java中的序列化，恢复的速度相对快。
2.RDB 是一个非常紧凑（compact）的文件，体积小，因此在传输速度上比较快，因此适合灾难恢复。
3.RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
4.RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

AOF
1.秒级存储，不容易丢失数据。
2.兼容性较高，由于是基于redis通讯协议而形成的命令追加方式，无论何种版本的redis都兼容，再者aof文件是明文的，可阅读性较好。

4.0版本以前，所有的操作都会记录到AOF中，并且合并重复的命令（例如:set key1 1,set key1 2,set key 1 3。最终文件在进行合并后就只会记录set key1 3这一条指令。）
4.0版本以后，启用了混合模式。比较老一些的数据会先以RDB的形式进行存储，后面的数据会以append的形式进行追加。