redis持久化 RDB AOF

 

一，为什么要持久化

 

分两种情况。

第一种：如果你的项目比较小，只是利用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