Redis与其他的key-value缓存相比有一个很大的不同点,redis支持数据的持久化,通过将内存中的数据持久化到磁盘中,下次重启直接加载继续使用,这避免了系统断电宕机导致数据丢失。Redis的持久化方式有两种:RDB和AOF。
一、RDB机制
RDB持久化方式是指在一定时间间隔内将内存中的数据以快照的形式写入到二进制文件中,文件名为dump.rdb,这是redis默认的持久化方式。“快照”就好比给数据进行拍照,只记录了某一时刻内存中的数据。
redis提供了三种方式来触发RDB机制:save、bgsave和自动触发。
- save触发方式:这种方式不推荐使用,因为在执行save命令期间,redis的主进程会被阻塞而无法继续处理客户端发送过来的命令请求。
- bgsave触发方式:与save命令不同,执行bgsave命令时,redis会fork出一条子进程来完成RDB持久化操作,这种方式只会在fork操作时发生短暂的阻塞,在子进程执行RDB持久化操作的同时,主进程依然可以继续处理客户端发送过来的命令请求。redis基本都使用这种方式来触发RDB机制。
- 自动触发方式:通过在redis.conf配置文件中配置来实现,格式为“save m n”,表示m秒内,数据如果发生n次修改则自动触发bgsave命令。
注意:RDB持久化方式是可能发生数据丢失的情况的,刚才说过这种持久化方式是将数据以快照的形式写入二进制文件中,而快照只是某一时刻内存中的数据,试想如果子进程高高兴兴地拿着这个快照去进行持久化了,而这期间主进程继续处理客户端的请求使得内存中的数据发生了修改,那么子进程仅凭手中的快照是无法得知数据已经被修改过了,也就是说主进程的修改在子进程是不会反应出来的,这样将会丢失持久化期间变化的数据内容。
二、AOF机制
AOF机制是将每一个写命令通过write函数保存到文件中,就好像日志记录一样,与RDB不同,AOF机制记录的不是内存中的数据,而是每一条命令。
这样随之而来一个问题:随着时间的推移,AOF文件体积会逐渐膨胀变得越来越大。为了解决这个问题,引入了“AOF文件重写机制”,该机制的原理将在后面谈到,重写之后的新AOF文件与旧文件相比,新旧两个文件所保存的数据库状态是相同的,但是新AOF文件不会包含浪费空间的冗余命令,因此文件重写机制能大大减小AOF文件的体积。
redis也提供了三种方式来触发AOF机制:always、everysec、no。
-
always:每次数据发生修改都会记录到磁盘,这种方式性能较差但数据完整性较好。
-
everysec:每秒记录一次数据,但如果一秒内发生了宕机,将会丢失这一秒钟内修改或新增过的数据。推荐使用这种方式。
-
no:从不同步数据。
三、RDB机制和AOF机制该如何选择?
正所谓小孩子才做选择,大人全都要。通常都是将两种机制结合使用比较好,当然如果场景特殊则参考下表自行定夺。
| RDB | AOF |
体积 | 小 | 大 |
恢复速度 | 快 | 慢 |
数据安全性 | 可能会发生数据丢失 | 根据策略决定 |
四、AOF文件重写原理
AOF重写并不需要对原来的AOF文件进行读取、写入和分析等操作,而是直接读取当前数据库状态来实现的。首先从数据库中读取键现在的值,然后用一条命令去记录键值对,用这一条命令代替之前记录该键值对的多个命令。
AOF文件重写涉及到两个重要的问题及解决办法如下。
1、aof_rewrite函数问题
AOF重写需要使用到aof_rewrite函数,这个函数会进行大量的写入操作,所以调用这个函数的线程将会发生长时间的阻塞,redis是使用单线程来处理命令的,如果直接使用aof_rewrite函数,那么redis将会在进行aof文件重写时无法处理客户端发送过来的命令请求。
解决这个问题的办法是将重写程序放入子进程中,子进程拥有主进程的数据副本,这样就能保证子进程在AOF文件重写期间,主进程依然能继续处理客户端的命令请求。
2、子进程进行文件重写存在的问题
看似完美,但使用子进程进行AOF文件重写时还会存在一个问题:子进程在进行文件重写期间,主进程依然能继续处理新的命令,如果新的命令使数据库数据发生了修改,那么当前数据库的数据和AOF重写之后的数据将会不一致。
为了解决这一问题,redis增加了一个AOF重写缓冲区,这个缓存在fork出子进程之后开始启用,Redis服务器主进程在执行完写命令之后,会同时将这个写命令追加到AOF缓冲区和AOF重写缓冲区,AOF缓冲区的内容会定期写入和同步到旧AOF文件中,这是为了保证旧AOF文件正常工作(因为此时新的AOF文件还没写完,所以旧的AOF文件需要正常工作),我们重点关注AOF重写缓冲区,从创建子进程开始,主进程所处理的所有写操作都会被记录到AOF重写缓冲区,当子进程完成AOF文件重写(此时的AOF文件中的数据和当前数据库数据状态可能会不一致)之后会向主进程发送一个完成信号,主进程接收到这个信号后将会调用一个函数来完成以下操作:将AOF重写缓冲区中的内容全部写入新的AOF文件中,此时的AOF文件中的数据和当前数据库数据状态一致;对新的AOF文件进行改名覆盖原有的旧AOF文件,最终完成新旧AOF文件的替换。