一,为什么要持久化
分两种情况。
第一种:如果你的项目比较小,只是利用redis 做为纯内存,存一字典、配置参数等少量的数据的话,那么是没必要开发持久化功能的。
第二种:项目比较大、用户量大、并发比较高、海量数量、为了提高响应速度将大量的数据放入缓存中。因为内存的资源是宝贵的、所以不可能将所有数据放入内存中,这时候一般情况下就需要进行缓存预热。经过预热后,将热点数据加载到内存中。
比如说我们的redis中经过预热环节,存入了大量的数据后,运行一段时间redis崩溃了,这时并发量又特别高,当没有缓存进行支撑,所以的流量都打到和原始服务、数据库,会引发雪崩的可能。如果说我们的redis崩溃后,重启redis能够快速将热点数据加载到内存中,可以减少系统的停机时间。这时就需要用到redis的持久化了。
二,redis提供哪些持久化机制
redis提供了两种持久化方式:RDB AOF
RDB :
简单理解,RDB就是redis内存某一个时间点的内存快照。
一般我们会定期生成RDB快照文件,进行本地备份或云备份。这种方式非常适合做内存数据的冷备。
优点:
1.生成快照时,对运行中redis的主进程影响小。因为他是fork一个子进程,子进行和主进行共享内存(linux操作系统的机制),所以可以查询遍历内存数据进行快照生成,当主进行对数据改变时是不会影响子进程的,因作系统的 COW(Copy On Write) 机制来进行数据段页面的分离,所以这种方式叫快照。
2.恢复速度快。他是直接读进RDB文件到内存中的。不需要重放等操作。
缺点:
1.一般来说RDB快照的生成周期较长,比如1小时或一天生成一次快照。这样的话,一但恢复数据到内存中,将会丢失1小时或一天的数据。
2.如果RDB生成的文件过大时,会导致redis对客户端暂停服务。所以RDB生成的时间间隔不要太大。尽量让每次生产的RDB文件小一些。
AOF:
简单理解为对redis内存数据进行修改的指令数据进行记录。
优点:
1.AOF日志文件以append-only模式写入,没有磁盘寻址的开销,写入性能非常高。
2.AOF是已日志文件的形式存在的,当对AOF日志文件写入时,其实是先写到内存缓存中(os cache),系统定期异步的刷到硬盘上的,这样就有一个问题,当系统未将内存缓存的数据刷到硬盘之前,系统down机了,就会导致数据丢失。为了解决这个问题,系统提供了一个 fsync(int fd)函数,强制将批量数据刷到硬盘上。
注意:redis收到客户端修改命令时,是先进行参数校验,然后写AOF文件,最后执行客户端的命令的。
AOF的fsync策略:
always:每个命令都调用fsync。性能非常差,因为有磁盘的IO操作
everysec:每妙强刷一次。这他参数比较长用。最多失掉1妙的数据,又保证了高性能。
no:永不 fsync——让操作系统来决定同步到磁盘中,容易丢失较多的数据。
3.AOF日志文件过大的时候,会进行重写操作,对文件瘦身。redis内存的容量是有限的,所以很多数据会进行过期 、删除、LRU清理等操作,这样会导致一些旧的数据内存中已经不存在了,但AOF文件中还有这些指令,导致数据不一致的情况 。所以这里也是fork一个子进程来进行重写操作的,对当前redis内存的数据进行遍历,反向生成命令、写入新AOF日志文件,再将操作过程中发生的增量追加上,将老文件替换。所以也不会对主进程性能操作影响。
缺点:
1.对写入性能是有影响的,因为是先写入AOF日志文件后再执行相关命令的。
2.AOF的日志文件相对于RDB是比较大的。
3.恢复速度比较慢,因为需要进行重放指令操作。
RDB和AOF如果选择:
建议两个同时开启。RDB进行冷备。恢复时优先选择AOF的方式,尽量减少数据的丢失。
redis4.0对持久化进行了优化。如果把混合持久化打开,AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头,默认是关闭的。
持久化相关参数配置:
https://www.cnblogs.com/itdragon/p/7906481.html