9、redis的持久化策略

最新推荐文章于 2024-11-15 09:12:58 发布

JavaDayUp-远行客

最新推荐文章于 2024-11-15 09:12:58 发布

阅读量615

点赞数

本文链接：https://blog.csdn.net/liubao616311/article/details/89187298

版权

学习目标：

1、了解Redis的持久化的使用

1、掌握Redis的持久化的配置

学习过程：

Redis是内存数据库，所以在服务器重启或者断电时，内存数据肯定会丢失，对于某些应用来说这是不可接收，例如如果使用Redis作为订单号的生成器，每一次都会逐次增1，如果断电重启后，订单号必须能够接着增1，而不是从0开始。所以Redis有必要持久化数据。当然如果你的业务仅仅只是用于简单的缓存，那么你也可以禁用持久化以提升效率。

Redis的有两种持久化策略：

rdb:快照形式是直接把内存中的数据保存到一个dump文件中，定时保存，保存策略
aof：把所有的对redis的服务器进行修改的命令都存到一个文件里，命令的集合

一、rdb方式

快照rdb持久化方式时安装redis时的默认方式，将内存中的数据以快照的方式写入二进制文件中，默认的文件名是dump.rdb，这些也都可以通过配置文件修改的。

redis.conf常见配置：

dbfilename "dump.rdb"

dir "/data/dbs/redis/6381"

save 900 1

save 300 10

save 60 10000

意义如下：

dbfilename "dump.rdb" #持久化文件名称

dir "/data/dbs/redis/6381" #持久化数据文件存放的路径

默认是如上配置：900秒之内，如果超过1个key被修改，则发起快照保存；

300秒内，如果超过10个key被修改，则发起快照保存

1分钟之内，如果1万个key被修改，则发起快照保存

rdb持久化工作原理简单：当redis需要做持久化时，redis会fork一个子进程；子进程将数据写到磁盘上一个临时RDB文件中；当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处就是可以copy-on-write。

RDB持久化也分两种：SAVE和BGSAVE

1、SAVE是阻塞式的RDB持久化，当执行这个命令时redis的主进程把内存里的数据库状态写入到RDB文件（即上面的dump.rdb）中，直到该文件创建完毕的这段时间内redis将不能处理任何命令请求。

2、BGSAVE属于非阻塞式的持久化，它会创建一个子进程专门去把内存中的数据库状态写入RDB文件里，同时主进程还可以处理来自客户端的命令请求。但子进程基本是复制的父进程，这等于两个相同大小的redis进程在系统上运行，会造成内存使用率的大幅增加。这种方式尤其需要注意的。如果redis本身内存使用率就60%，总的内存使用率在80%左右，持久化的时候立马占到100%以上的。

可以使用命令操作的。

127.0.0.1:6379> bgsave

Background saving started

127.0.0.1:6379> save

从上面的配置可知，rdb方式不能完全保证数据持久化，因为是定时保存，所以当redis服务down掉，就会丢失一部分数据，而且数据量大，写操作多的情况下，会引起大量的磁盘IO操作，会影响性能。

二、aof方式

使用aof做持久化，每一个写命令都通过write函数追加到appendonly.aof中.配置方式：启动aof持久化的方式

appendonly yes

Append-only方法可以做到全部数据不丢失，但redis的性能就要差些。AOF就可以做到全程持久化，只需要在配置文件中开启（默认是no），appendonly yes开启AOF之后，redis每执行一个修改数据的命令，都会把它添加到aof文件中，当redis重启时，将会读取AOF文件进行“重放”以恢复到redis关闭前的最后时刻。

LOG Rewriting随着修改数据的执行AOF文件会越来越大，其中很多内容记录某一个key的变化情况。因此redis有了一种比较有意思的特性：在后台重建AOF文件，而不会影响client端操作。在任何时候执行BGREWRITEAOF命令，都会把当前内存中最短序列的命令写到磁盘，这些命令可以完全构建当前的数据情况，而不会存在多余的变化情况（比如状态变化，计数器变化等），缩小的AOF文件的大小。所以当使用AOF时，redis推荐同时使用BGREWRITEAOF。

AOF文件刷新的方式，有三种，参考配置参数appendfsync ：

appendfsync always每提交一个修改命令都调用fsync刷新到AOF文件，非常非常慢，但也非常安全；

appendfsync everysec每秒钟都调用fsync刷新到AOF文件，很快，但可能会丢失一秒以内的数据；

appendfsync no依靠OS进行刷新，redis不主动刷新AOF，这样最快，但安全性就差。默认并推荐每秒刷新，这样在速度和安全上都做到了兼顾。

appendonly yes //启用aof持久化方式

# appendfsync always //每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用

appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐

# appendfsync no //完全依赖os，性能最好,持久化没保证

可能由于系统原因导致了AOF损坏，redis无法再加载这个AOF，可以按照下面步骤来修复：首先做一个AOF文件的备份，复制到其他地方；修复原始AOF文件，执行：$ redis-check-aof –fix ;可以通过diff –u命令来查看修复前后文件不一致的地方；重启redis服务。

redis-check-aof --fix appendonly.aof

三、Redis 4.0版本后支持---混合持久化
Redis 4.0有一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。AOF文件的前半段是RDB格式的全量数据后半段是redis命令格式的增量数据。

修改配置

aof-use-rdb-preamble yes #默认时没有开启混合持久化的改成yes

我们先看看原来的aof文件

[root@localhost redis]# cat appendonly.aof
*2
$6
SELECT
$1
0
*3
$3
set
$4
name
$6
liubao
*2
$6
SELECT
$1
0
*3
$3
set
$3
age
$3
456
*2
$6
SELECT
$1
0
*3
$3
set
$3
msg
$5
hello