redis的持久化

redis的持久化

RDB

是什么

在指定的时间间隔内将内存中的数据集快照写入磁盘。

备份是如何执行的

Redis会单独创建一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化进程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失

redis.conf中的一些参数

dbfilename dump.rdb 默认的持久化文件的名字

dir ./ 指定在启动目录中创建rdb文件

stop-writes-on-bgsave-error yes 当Redis无法写入磁盘的话，直接关掉Redis的写操作。推荐yes

rdbcompression yes 持久化文件是否进行压缩存储

rdbchecksum 检查数据完整性

save 格式：save 秒数 写操作次数 经过多少秒写了多少次操作之后才进行持久化操作

save和bgsave的区别：

save: save时只管保存，其他不管，全部阻塞。手动保存。不建议。

bgsave： Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。

优势

• 适合大规模的数据恢复

• 对数据完整性和一致性要求不高更适合使用

• 节省磁盘空间

• 恢复速度快

劣势

• Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

• 虽然Redis在fork时使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能。

• 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照的所有修改。

 

AOF

是什么

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构造数据，换言之，redis重启的话就根据日志文件的内容将写指令从前往后执行一次以完成数据的恢复工作。AOF默认不开启，如果AOF和RDB同时开启，系统默认读取AOF的数据（数据不存在丢失）

异常恢复

• 修改默认的appendonly no，改为yes

• 如遇到AOF文件损坏，通过./redis-check-aof --fix appendonly.aof进行恢复

• 备份被写坏的AOF文件

• 恢复：重启redis，然后重新加载

AOF同步频率设置

appendfsync always/everysec/no

• always : 始终同步，每次Redis的写入都会立刻写入日志；性能较差但是数据完整性比较好。

• everysec : 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

• no : redis不主动进行同步，把同步时机交给操作系统。

AOF持久化流程

1. 客户端的请求写命令会被append追加到AOF缓冲区内；

2. AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

3. AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

4. Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的。

优势

• 备份机制更稳健，丢失数据概率更低。

• 可读的日志文本，通过操作AO文件，可以处理误操作

劣势

• 比起RDB占用更多的磁盘空间

• 恢复备份速度要慢

• 每次读写都同步的话，有一定的性能压力

• 存在个别Bug，造成不能恢复

 

两者如何选择

• 官方推荐两个都启用

• 如果对数据不敏感，可以单独使用RDB

• 不建议单独使用AOF，因为可能会出现Bug

• 如果只是做纯内存缓存，可以都不用