redis持久化原理详解

「爱情、让人受尽委屈。」 2022-07-11 12:20 175阅读 0赞

# 一、 Redis 提供了不同级别的持久化方式: #

Redis提供了两种方式对数据进行持久化，分别是RDB和AOF。   
RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。   
AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。   
如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。   
你也可以同时开启两种持久化方式,，在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

# 二、 配置文件中对两种存储方式的设置 #

Redis默认开启RDB的存储方式。   
The filename where to dump the DB   
dbfilename “dump.rdb”   
对于AOF的存储方式redis并没有默认开启。通过配置开启如下：   
![这里写图片描述][SouthEast]   
把注释去掉就开启了AOF的存储方式。

# 三、 RDB（Redis DataBase）介绍 #

开启RDB方式redis会在指定的时间段内将内存中的数据快照到磁盘中，redis启动时再恢复到内存中。   
Redis会单独创建（fork）一个线程，将数据写入到临时文件中，持久化的过程都结束了，在用这个临时文件替换上次的临时文件。   
如果需要进行大规模的数据恢复，并且对于数据恢复不是很敏感，RDB的方式比AOF方式更加高效，RDB的缺点就在于最后一次持久化后的数据有可能会丢失。   
RDB持久化数据触发配置在redis.conf中：   
![这里写图片描述][SouthEast 1]   
默认是当一条数据写入时15分钟持久化一次，当10条数据发生变化5分钟（为了测试方便改成了2分钟）持久化一次，当10000条数据发生变化1分钟进行持久化。   
RDB存储方式测试：   
![这里写图片描述][SouthEast 2]   
两分钟后在文件夹中生成了一个dump.rdb的文件，这个就是临时文件，保存该临时文件。   
![这里写图片描述][SouthEast 3]   
再次清空[数据库][Link 1]：   
![这里写图片描述][SouthEast 4]   
然后删除dum.rdb文件，将dump.rdb.bk文件恢复成dump.rdb。再启动服务器。   
![这里写图片描述][SouthEast 5]   
如上图所示，redis中的数据已经从dump.rdb中恢复过来了。

# 四、 AOF（APPEND ONLY FILE）存储介绍 #

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，   
只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis   
重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。   
注：所有的指令记录也包括flushDB操作，后面会有坑。   
在redis中这种存储方式默认是关闭的，需要在redis.conf文件中开启，开启方式在文中已经做了介绍，就不在赘述。   
Redis对于AOF存储方式是怎么持久化的在redis.conf也有，如下：   
![这里写图片描述][SouthEast 6]   
配置文件对于这种方式的持久化有三种方式：   
1、 有写操作就写。显然这种方式影响性能。但是数据完整，不会丢数据   
2、 不开启。不开启AOF就没意思了   
3、 每秒写文件。折中的方式更加合适。但是有可能导致一秒的数据丢失。

## AOF的重写（Rewrite） ##

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,   
当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩。

## 重写原理 ##

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

## 触发机制： ##

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。   
![这里写图片描述][SouthEast 7]

## AOF存储方式优点： ##

1、 每秒同步。   
2、 每修改同步。

## AOF存储方式缺点： ##

1、 AOF文件远大于EDB。   
2、 运行效率慢。

## AOF存储方式测试： ##

1、写入数据   
![这里写图片描述][SouthEast 8]   
3、 写入之后在文件夹中出现了AOF文件，再对这个文件进行备份   
![这里写图片描述][SouthEast 9]  
4、 清空数据库并退出   
![这里写图片描述][SouthEast 10]   
5、 恢复appendonly.aof文件   
![这里写图片描述][SouthEast 11]  
6、 启动redis服务器，查看数据   
![这里写图片描述][SouthEast 12]   
如图所示数据已经恢复。

# 五、 同时开启了RDB和AOF两种方式默认是哪种方式？ #

从刚才测试AOF可以看出两种方式同时开启是使用AOF的存储方式。   
![这里写图片描述][SouthEast 13]  
当只开启了RBD方式时数据库中有10条数据，当开启了AOF方式之后，由于appendonly.aof文件中没有备份数据，所以启动后如第二个框中框出的所示没有数据。从这里可以看出默认首先使用AOF的存储方式。

# 六、 小结 #

1、 同时开启两种方式优先使用AOF方式。   
2、 一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。   
3、 如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。   
4、 有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。

[SouthEast]: /images/20220711/a95cf6b56de340f581169c0af093efcd.png
[SouthEast 1]: /images/20220711/f1b5d143afac41d68b8b38d88c7d861b.png
[SouthEast 2]: /images/20220711/25999360150649798f1c34a03a2545b5.png
[SouthEast 3]: /images/20220711/752ad3b5350640cc8221011751b2673b.png
[Link 1]: http://lib.csdn.net/base/14
[SouthEast 4]: /images/20220711/3c8497b2cdae495ca1b7a498ef781038.png
[SouthEast 5]: /images/20220711/c6bc0f9b91b34401bba31ff2c73be43c.png
[SouthEast 6]: /images/20220711/34eaeb181f31462fa7410babb1513e57.png
[SouthEast 7]: /images/20220711/112202f4b1084229af4bdb187385c1ac.png
[SouthEast 8]: /images/20220711/2a9a06f60b924c159c74f411048310ef.png
[SouthEast 9]: /images/20220711/ff39bdd2037f46a59382aeae3ed4fa00.png
[SouthEast 10]: /images/20220711/ee257c1c72954de8a5e4bfbbaf08a5ca.png
[SouthEast 11]: /images/20220711/a0bb858b859a40ffa81358b7ad13f7cc.png
[SouthEast 12]: /images/20220711/627ebf9842764e03adf80c282cf00cbd.png
[SouthEast 13]: /images/20220711/f21d0c39fd5c46b791ccb98a41bda711.png