Redis系列之持久化机制RDB/AOF

RDB

介绍

RDB，全程Redis DataBase，这种持久化方式是指数据集快照的方式实现半持久化，在某个时间点将数据写入一个临时文件，记录redis数据库的所有键值对信息，持久化结束之后，用这个临时文件替代上次持久化的文件，达到数据恢复的效果

优点

1、持久化的文件是dump.rdb，只有这一个文件，方便持久化

2、容灾性较好，一个文件可以保存到安全的磁盘上

3、性能好，在rdb对数据做持久化时，是启用一个fork子进程来完成写操作，让主进程处理请求的命令，所以IO的操作大多数在fork子进程那里来完成，主进程不会进行IO操作，从而保证了redis的读写高性能

4、在大量数据下，比AOP的启动效率要高 

缺点

1、数据安全性较低，因为RDB持久化机制是间隔一段时间才会进行，如果这段时间之内，redis发生故障就会导致数据丢失，所以使用RDB一般是用于某个场景下数据不严谨或者不是特别重要的时候 

个人补充

其实有兴趣的童鞋可以打开RDB文件就可以发现，文件里面记录的都是进制乱码，乍一看确实看不懂，但是有些信息我们是可以看得懂的也是能看得到的，大家仔细观察，其实能够发现，rdb文件中会存在我们set进去的key和value，比如我执行一个命令：set name caobing，那rdb文件中就会存在一个name和一个caobing，所以在恢复数据的时候，它是相当于直接把key和value全部一次性加载到内存上，这样的速度会很快，说到这里，其实就可以把rdb文件当做是一张表，记录了各种key和value，如图

 

---

AOF

介绍

AOF，全程Append-only file， 它的实现方式是把所有执行的命令记录到aof文件中，可以理解为我们开发系统中的一个操作日志，把我们执行的命令全部记录了下来，保存在aof文件中

优点 

1、数据安全性较好，aof持久化提供了一个appendfsync的属性，其中有个always选项，这个选项就是会把每一次命令都记录到aof中

2、通过append模式进行写操作，即使中途redis宕机了，也可以通过redis-check-aof工具解决数据一致性的问题

3、AOF提供了rewrite机制，只会记录最终的命令，比如：我第一次set name zhangsan，第二次对name赋值lisi，第三次赋值wangwu，rewrite启动之后，我只会记录wangwu，如果不开启，那aof会把zhangsan、lisi、wangwu都记录在aof文件中，这样的话就对文件大小的空和写操作的性能有一定的提升 

缺点 

1、AOF文件比RDB文件要大，相对恢复速度慢，毕竟aof恢复数据相当于把我们执行的命令再执行一遍，rdb是直接恢复数据，所以相对比较慢

2、数据量大的时候，启动效率会比rdb要低，同1中讲到的一样，它要一个一个执行命令