Redis持久化
1、持久化
1.1、RDB快照(snapshot)
1.1.1、RDB快照简单配置与说明
Redis默认会开启RDB快照。
在默认情况下, Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。 你可以对 Redis 进行设置, 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时, 自动保存一次数据集(默认是bgsave)。
比如说, 以下设置会让 Redis 在满足“ 60 秒内有至少有10000 个键被改动”这一条件时, 自动保存一次。
在redis.conf中的配置如下图所示,可配置多个策略:
当然我们也可以手动的让redis去执行持久化,更新dump.rdb文件,我们可以进入到redis客户端,输入save命令或者bgsave命令
save命令是同步执行更新文件,如果文件过大的话,可能会产生卡顿
bgsave(back ground save)是异步更新文件
下面是文件的更新时间
然而这个dump.rdb文件的保存位置配置如下图所示,在redis.conf的同级目录下:
保存的文件名称也可以改,如下图所示:
1.1.2、bgsave的写时复制(COW)机制
Redis借助操作系统提供的写时复制技术(Copy-On-Write),在生成快照的同时,依然可以正常处理写命令。
当需要保存快照的时候,Redis主线程会fork一个子线程,这个子线程会去进行rdb文件的写入,主线程和bgsave子线程互不影响。但是如果主线程需要修改一块数据,那么,这块数据就会被复制一份,生成该数据的副本。然后,bgsave 子进程会把这个副本数据写入 RDB 文件,而在这个过程中,主线程仍然可以直接修改原来的 数据。写时复制机制保证快照期间数据可修改,这既保证了快照的完整性,也允许主线程同时对数据进行修改,避免了对正常业务的影响。
1.1.3、save和bgsave的区别
save | bgsave | |
---|---|---|
IO类型 | 同步 | 异步 |
是否阻塞redis其它命令 | 是 | 否(在生成子进程执行调用fork函 数时会有短暂阻塞) |
复杂度 | O(n) | O(n) |
优点 | 不会消耗额外内存 | 不阻塞客户端命令 |
缺点 | 阻塞客户端命令 | 需要fork子进程,消耗内存 |
1.1.4、RDB可能会出现的问题
1、RDB如果配置的条件过低的话,比如一秒钟有一次数据修改就做数据持久化,这样子就会非常的消耗性能,因为RDB是将Redis配置的整个内存做持久化处理的。
2、RDB如果配置的条件过高的话,长时间没有做数据持久化,如果中间Redis出现宕机等各种意外情况的话,就会产生丢失数据的问题。
1.2、AOF(append-only file)
1.2.1、AOF配置
1、开启AOF配置
appendonly yes
2、AOF快照文件名称配置
appendfilename “appendonly.aof”
3、AOF快照策略配置
策略 | 含义 |
---|---|
appendfsync always | 每有一个操作值的动作,都会把这个动作记录在aof文件中 |
appendfsync everysec | 每一秒钟给aof记录一次(将这一秒中的所有操作) |
appendfsync no | 不会主动去记录,让操作系统去检测某一个时间可能系统不是很忙,然后去将这段时间的所有操作记录在aof文件中 |
1.2.2、AOF快照简单阐述
一般情况下,一条命令是以* 开头的,如下图所示
我当时执行的命令是 set times 600
快照记录 | 含义 |
---|---|
*3 | 代表这条命令有三个参数 |
$3 | 代表第一个参数的长度(set) |
set | 代表第一个参数 |
$5 | 代表第二个参数长度 |
times | 代表第二个参数 |
$3 | 代表第三个参数长度 |
600 | 代表第三个参数 |
1.2.3、AOF重写
1、AOF重写是什么?
AOF重写是当我们给aof文件写了很多命令的时候,发现有一部分命令其实很冗余,占用的内存空间比较大,可以使用另外一些少部分命令去代替它,最终的结果是不会改变的,将很多的命令用少部分命令代替以节省内存空间,这就叫做AOF重写。
2、AOF重写的配置
1、auto‐aof‐rewrite‐min‐size 64mb: aof文件至少要达到64M才会自动重写,文件太小恢复速度本来就 很快,重写的意义不大。
2、auto‐aof‐rewrite‐percentage 100:aof文件自上一次重写后文件大小增长了100%则再次触发重写,就比如说第一次重写完成之后,内存占用50M,然后下一次当内存达到100M时就会重写。
3、手动执行AOF重写
我们只需要在客户端输入下面命令即可
bgrewriteaof
重写前AOF文件如下:
重写后AOF文件,效果如下:
1.3、RDB和AOF的优缺点
方面点 | RDB | AOF |
---|---|---|
启动优先级 | 低 | 高 |
体积 | 小(二进制压缩数据存储) | 大 |
恢复速度 | 快 | 慢 |
数据安全性 | 容易丢数据 | 根据策略决定 |
1.4、Redis混合持久化
在redis4.0版本之后提供了这样一个参数, 它结合了aof和rdb的优点,在每一次aof持久化的时候,会将aof持久化之后的数据转换成二进制的形式存储在aof文件中,配置方式如下所示,需要时可开启,配置生效的前提是AOF持久化必须开启。
aof‐use‐rdb‐preamble yes
持久化执行前
持久化执行后
但是我们新增加的修改操作却又是命令格式存放在aof文件中,如下所示:
1.5、Redis数据备份策略
- 写crontab定时调度脚本,每小时都copy一份rdb或aof的备份到一个目录中去,仅仅保留最近48 小时的备份
- 每天都保留一份当日的数据备份到一个目录中去,可以保留最近1个月的备份
- 每次copy备份的时候,都把太旧的备份给删了
- 每天晚上将当前机器上的备份复制一份到其他机器上,以防机器损坏