持久化机制
尽管 Redis 是基于内存的 key-value 服务,但也可以进行数据的持久化,以便服务重启,数据能重新加载进来。
为了尽可能的保证数据不丢失,Redis 为我们提供了好几种持久化机制:
- RDB:即 Redis Database,在指定的时间间隔里将 Redis 内存数据镜像下来,保存到文件里。
- AOF:将服务器对数据的写操作追加到文件里,相当于将所有的逻辑操作都记录了下来。
- 无持久性:不进行持久化,性能最好。
- RDB + AOF:将 RDB 和 AOF 结合起来,组合它们各自的优点。
下面,我们来看看这些机制吧。
RDB 配置
在 redis.conf
文件里我们可以针对 RDB 持久化方式进行设置:
### 快照设置 ###
# save "" 空表示不进行持久化
save 900 1 # 900 秒内如果有1个 key 值改变,则进行持久化动作
save 300 10 # 300 秒内如果有10个 key 值改变,则进行持久化动作
save 60 10000 # 60 秒内如果有10000个 key 值改变,则进行持久化动作
# 如果持久化失败,则 Redis 不会再进行数据更新操作,直到恢复正常
stop-writes-on-bgsave-error yes
# 是否对持久化的 rdb 文件进行压缩保存
rdbcompression yes
# 是否对持久化的 rdb 文件进行校验
rdbchecksum yes
# 要持久化的 rdb 文件名
dbfilename example.rdb
# 导出目录
dir /opt/redisdata
RDB 优势
- 当 Redis 进行持久化动作时,它会先 fork 一个子进程,将数据的写入交给子进程,而父进程不会涉及到磁盘的 IO 操作,所以 RDB 的性能非常好。
- 如果是在 Unix 系统上,还能充分利用写时复制机制。也就是子进程和父进程共用相同的内存页面,只有当子进程或父进程进行修改才会进行复制。这样节省了对物理内存的使用。
- 由于 RDB 文件只存储了某个时刻的内存数据,并没有什么逻辑命令,所以在进行重启恢复时,能很快的加载进来。
RDB 缺点
- 虽然 RDB 的 fork 能使得 Redis 的持久化独立进行,但是一旦数据量比较大的,就会一直占用 CPU,可能会影响到父进程的进行。
- 前面的 RDB 配置里我们提到是按一定的时间间隔内去触发持久化的,但也正是因为这个时间间隔原因,导致我们将会有一定概率在这段时间内丢失数据。
AOF 配置
同样的,我们可以在 redis.conf
文件里对 AOF 持久化进行配置:
appendonly no # 是否开启 aof
appendfilename "appendonly.aof" # aof 文件名
# 同步到磁盘的策略 默认每秒一次
# appendfsync always # 每次
appendfsync everysec # 每秒一次
# appendfsync no # 由操作系统执行,默认Linux配置最多丢失30秒
auto-aof-rewrite-percentage 100 # aof 文件超过比例则进行重写
auto-aof-rewrite-min-size 64mb # aof 文件超过多少则进行重写
aof-load-truncated yes # 如果 aof 最后的指令有误,则在重新恢复时忽略。
在上面的配置中,我们看到有关 aof 文件重写的配置。之所以需要对 aof 进行重写,是因为 aof 文件记录的是逻辑操作。随着系统运行越久,操作命令将越来越多,日志文件也就越来越大了,所以需要对其进行重写,以减少磁盘空间。
当 AOF 进行文件重写时,会将内存数据重新整理一遍,然后保存到新文件里,接着再将新文件替换原来的 AOF 文件。
AOF 优势
- AOF 让我们可以以每秒的速度进行持久化,这样的话可以很大程度的减少数据的丢失。
- AOF 采用追加的方式进行写文件,这样即使持久化失败,影响较少,而且能够使用 redis-check-aof 进行修复。
AOF 缺点
- 前面提到过日志会越来越大,需要靠重写来减少对磁盘的占用。
混合持久化
为了能将 AOF 和 RDB 的优势结合起来, Redis 在 4.0 之后启用了混合持久化,它的配置如下:
aof-use-rdb-preamble yes
当开启了混合持久化后,Redis 会 fork 子进程将内存数据以 RDB 格式写入 AOF 文件,后面会将重写缓冲区的增量命令以 AOF 方式写入到文件。这样的话,新的 AOF 文件就同时拥有了 2 种格式的数据。
当需要使用混合文件进行恢复时,会先判断 AOF 文件的头部是否为 RDB 格式,是的话,先使用 RDB 的方式加载数据,接着再处理后面的 AOF 数据。
这样的话就能加快数据的恢复速度,又降低了数据丢失的风险。
当然, 这种混合方式会使得 AOF 文件变得复杂,可读性差,而且得是 4.0 版本以上才能使用。
总结
Redis 的持久化都有它的特点,那我们应该选择哪种机制呢?
- 如果我们的数据允许丢失,那应该关闭持久化方式,这样性能会很好。
- 如果我们希望能尽量的保证数据的安全性,那我们应该选择混合持久化方式。
- 如果我们希望保证数据不丢失,那应该选择 appendfsync 为 always,只是这种对性能影响很大,所以一般都会直接考虑 mysql 了。