关于redis:redis-系列持久化机制

1次阅读

共计 2110 个字符，预计需要花费 6 分钟才能阅读完成。

只管 Redis 是基于内存的 key-value 服务，但也能够进行数据的长久化，以便服务重启，数据能从新加载进来。

为了尽可能的保证数据不失落，Redis 为咱们提供了好几种长久化机制：

RDB：即 Redis Database，在指定的工夫距离里将 Redis 内存数据镜像下来，保留到文件里。
AOF：将服务器对数据的写操作追加到文件里，相当于将所有的逻辑操作都记录了下来。
无持久性：不进行长久化，性能最好。
RDB + AOF：将 RDB 和 AOF 联合起来，组合它们各自的长处。

上面，咱们来看看这些机制吧。

在 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

当 Redis 进行长久化动作时，它会先 fork 一个子过程，将数据的写入交给子过程，而父过程不会波及到磁盘的 IO 操作，所以 RDB 的性能十分好。
如果是在 Unix 零碎上，还能充分利用写时复制机制。也就是子过程和父过程共用雷同的内存页面，只有当子过程或父过程进行批改才会进行复制。这样节俭了对物理内存的应用。
因为 RDB 文件只存储了某个时刻的内存数据，并没有什么逻辑命令，所以在进行重启复原时，能很快的加载进来。

尽管 RDB 的 fork 能使得 Redis 的长久化独立进行，然而一旦数据量比拟大的，就会始终占用 CPU，可能会影响到父过程的进行。
后面的 RDB 配置里咱们提到是按肯定的工夫距离内去触发长久化的，但也正是因为这个工夫距离起因，导致咱们将会有肯定概率在这段时间内失落数据。

同样的，咱们能够在 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 采纳追加的形式进行写文件，这样即便长久化失败，影响较少，而且可能应用 redis-check-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 了。

感兴趣的敌人能够搜一搜公众号「阅新技术」，关注更多的推送文章。
能够的话，就顺便点个赞、留个言、分享下，感激各位反对！
阅新技术，浏览更多的新常识。

正文完