redis作为目前的最主流的缓存解决方案。但是有一个问题,我想大家一定都有过思考:如果服务器突发状况宕机,内存中的数据丢失了,我们该如何恢复数据?
首先我们想到的肯定是从数据库中恢复数据,但是这种方案存在两个问题:
第一,如果数据量比较大,从数据库恢复会给数据库带来很大的压力;第二,从数据库恢复数据,性能肯定比不上从redis中直接读取。因此实现数据的持久化,对于redis宕机恢复是至关重要的。
目前redis支持的持久化方式主要有两种:AOF(Append Only File)操作日志和RDB内存快照。
AOF
说道日志,我们比较熟悉的是数据库的写前日志(WRITE AHEAD LOG,WAL),也就是在实际的数据写入之前,先将需要修改的数据记录到日志文件中去,便于发生故障时,进行数据恢复。但是redis的AOF日志恰好相反,属于写后日志。具体的意思是,当redis的命令执行成功后,才将操作命令作为日志记录下来。如下图
redis为什么采用这种方式?是因为redis的日志文件里面记录的是redis执行的每一条命令。为了避免AOF文件中记录到错误的命令,同时减少命令正确性检查的开销,redis会先执行这些命令,执行成功了才向日志文件中写入命令,保证了记录的每条命令都是可以正确执行的;还有一个重要的原因是在执行命令后再记录日志,不会阻塞当前的写操作。
AOF也有两个潜在的风险:
- 如果刚执行完一条命令,还未来得及记录日志,就宕机了,会存在数据丢失的风险。
- AOF虽然不会阻塞当前操作,但可能会阻塞下一条命令操作,这是因为AOF也是在主线程中进行的。
针对上面的两个问题,redis提供了三种日志写回策略,也就是AOF的配置项appendfsync的三个可选值;
- always——同步写回,命令执行完成后,立即将日志写入磁盘
- everysec——每秒写回,命令执行完成后,只是先把命令写入AOF的缓冲区,每隔一秒钟,从缓冲区中将日志写入磁盘,redis默认的配置
- no——操作系统控制写回,命令执行完成后,只是先把命令写入AOF的缓冲区,具体什么时候写入磁盘由操作系统来决定
针对三种写回策略的优缺点总结如下:
可能有很多同学会有疑问,AOF文件记录的是操作命令,随着时间的推移,AOF文件肯定会越来越大,宕机恢复数据时,如果加载很大的文件,效率也是很低的?
针对这一问题,redis提供了AOF文件重写机制,具体的过程是:Redis 根据数据库的现状创建一个新的 AOF 文件。也就是读取数据库中的所有键值对,然后对每一个键值对用一条命令记录它的写入。比如说,当读取了键值对“str:k”: “str:v”之后,重写机制会记录 set str:k str:v 这条命令。这样,当需要恢复时,可以重新执行该命令,实现“str:k”: “str:v”的写入。
与AOF日志由主线程写回不同的是,AOF重写是由后台子进程bgrewriteaof,避免了主线程的阻塞,导致性能下降。
RDB
与AOF记录操作命令不同的是,RDB(内存快照)记录的是某一时间点内存中的数据,是真实的数据。因此,通常来说RDB文件的大小肯定是小于AOF文件的。在进行数据恢复的时候我们可以直接把RDB文件读入内存,很快地完成数据的恢复。但是内存快照就一定是最优解吗?答案是不一定。因为我们还需要考虑一个问题:多久做记录快照?
当然,肯定是时间间隔越小越好,因为这样降低了数据丢失的风险。虽然说redis在做快照时执行bgsave不会阻塞主线程,但是如果频繁地执行快照,也会带来两方面的开销:
一方面是,频繁地写入磁盘数据,会给磁盘带来很大的压力,多个快照记录竞争有限的磁盘带宽,前一个还没有做完,后一个又开始了,容易造成恶性循环。
另一方面,虽然bgsave不会阻塞主线程,但是bgsave子进程需要fork操作从主线程创建出来,在fork的过程中会阻塞主线程,同时,主线程的内存越大,fork的过程就越耗时,阻塞时间越长。
总结
持久化是保证redis数据可靠性的有效手段,因此,在redis使用的过程中,做好数据的持久化,是很必要的。在redis4.0 中提出了一个同时使用AOF和RDB的方法。具体的做法是:内存快照以一定的频率执行,在两次快照之间,使用AOF记录这期间的操作命令。这样的话,快照不用很频繁地执行,这就避免了频繁 fork 对主线程的影响。而且,AOF 日志也只用记录两次快照间的操作,也就是说,不需要记录所有操作了,因此,就不会出现文件过大的情况了,也可以避免重写开销。