redis 系列:持久化机制

持久化机制

尽管 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 了。


    感兴趣的朋友可以搜一搜公众号「 阅新技术 」,关注更多的推送文章。
    可以的话,就顺便点个赞、留个言、分享下,感谢各位支持!
    阅新技术,阅读更多的新知识。
    阅新技术

你可能感兴趣的