redis持久化

Posted 2020-12-14 happily-ye

一、为什么要做redis的持久化

　　redis是 key - value结构的内存数据库。作为内存数据库，不可避免的会有服务重启则数据丢失的问题。为了数据的安全，redis引入持久化来解决服务停止则数据丢失的问题。

二、Redis持久化机制

　　redis持久化有两种 RDB（默认开启）和 AOF（默认关闭）。

　　1、RDB持久化 是对redis中的数据进行周期性的持久化。RDB文件是经过压缩的二进制文件。

　　　　手动触发 

　　　　　　① 使用 SAVE 命令。暂停前端其他的读写操作。将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。

　　　　　　②使用BGSAVE 命令。BGSAVE 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。

　　　　自动触发

　　　　　　使用配置 SAVE m n。m表示秒，n表示修改次数。如save 900 1表示当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave。可配置多个，当任意一个save满足条件时就会bgsave。

　　　　　　具体实现：本质上是一个定时器事件。默认每隔100ms 通过serverCron函数、dirty计数器、和lastsave时间戳来实现的。对于每一个save m n条件，只有下面两条同时满足时才算满足：

　　　　　　　　（1）当前时间-lastsave > m

　　　　　　　　（2）dirty >= n 

　　　　常用的配置

// 默认是打开RDB持久化save m n：bgsave自动触发的条件；如果没有save m n配置，相当于自动动的RDB 持久化关闭，不过此时仍可以通过其他方式触发 
stop-writes-on-bgsave-error yes：
//当bgsave出现错误时，Redis是否停止执行写命令；设置为yes，则当硬盘出现问题时，可以及时发现，避免数据的大量丢失；设置为no，则Redis无视bgsave的错误继续执行写命令，当对Redis服务器的系统(尤其是硬盘)使用了监控时，该选项考虑设置为no 
rdbcompression yes 
//是否开启RDB文件压缩 rdbchecksum yes：是否开启RDB文件的校验，在写入文件和读取文件时都起作用；关闭checksum在写入文件和启动文件时大约能带来10%的性能提升，但是数据损坏时无法发现 
dbfilename dump.rdb
//RDB文件名 
dir ./ 
//：RDB文件和AOF文件所在目录 

　　

　　2、AOF持久化类似mysql的基于语句的binlog方式，即每条会使Redis内存数据发生改变的命令都会追加到一个log文件中，也就是说这个log文件就是Redis的持久化数据。

　　　　手动触发

　　　　　　使用bgrewriteaof命令：Redis主进程fork子进程来执行AOF重写，这个子进程创建新的AOF文件来存储重写结果，防止影响旧文件。**因为fork采用了写时复制机制，子进程不能访问在其被创建出来之后产生的新数据。

　　　　　　Redis使用“AOF重写缓冲区”保存这部分新数据，最后父进程将AOF重写缓冲区的数据写入新的AOF文件中然后使用新AOF文件替换老文件。

　　　　自动触发

　　　　　　和RDB一样，配置在redis.conf文件里：使用配置 appendonly 是否打开AOF持久化功能，

　　　　　　　　　appendonly默认是 no, 不开启AOF持久化。改成appendonly yes。

　　　　　　　　　appendfilename：AOF文件名称

　　　　　　　　　appendfsync：同步频率， no：写入aof文件，不等待磁盘同步 。always：总是写入aof文件，并完成磁盘同步。everysec：每一秒写入aof文件，并完成磁盘同步（默认）。

　　　　　　　　　auto-aof-rewrite-min-size：如果文件大小小于此值不会触发AOF，默认64MB

　　　　　　　　　auto-aof-rewrite-percentage：Redis记录最近的一次AOF操作的文件大小，如果当前AOF文件大小增长超过这个百分比则触发一次重写，默认100

 

三、RDB和AOF的比较

　　1、性能：RDB方式的性能是要明显高于AOF方式

　　　　①  采用二进制方式存储数据，数据文件比较小，加载快速。

　　　　② 存储的时候是按照配置中的save策略来存储，每次都是聚合很多数据批量存储，写入的效率很好，而AOF则一般都是工作在实时存储或者准实时模式下。相对来说存储的频率高，效率却偏低。

　　2、数据安全：AOF方式的数据安全高于RDB方式

　　　　① RDB存储是基于累计批量的思想，也就是说在允许的情况下，累计的数据越多那么写入效率也就越高，但数据的累计是靠时间的积累完成的，那么如果在长时间数据不写入RDB，但Redis又遇到了崩溃，那么没有写入的数据就无法恢复了，

　　　　　　但是AOF方式偏偏相反，根据AOF配置的存储频率的策略可以做到最少的数据丢失和较高的数据恢复能力。

　　3、RDB优点

　　　　① 备份策略方便：一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。

　　　　② 灾难恢复方便：，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

　　　　③ 性能最大化：对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

　　　　④ 启动效率高：相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

　　4、RDB缺点

　　　　① 数据的可靠性不高，没办法做到实时持久化

　　　　② 如果使用SAVE命令保存数据（2.0版本之前），数据集过大时可能导致服务暂停1秒，甚至更长的时间

　　5、AOF优点

　　　　① 数据安全性

　　　　② 数据一致性

　　6、AOF缺点

　　　　① 恢复速度慢，性能低：对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

 

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。