Redis持久化介绍

Redis是一个基于BSD开源许可的内存数据结构存储系统，由于redis具有卓越的高并发读写特性，其主要用于用作数据库、缓存和消息代理。redis具有内置的复制、lua、lru、事务和不同级别的磁盘持久性，并通过哨兵机制和集群自动分区功能提供高可用性。本文主要介绍包含RDB（Redis DataBase）持久化、AOF（Append Only File）持久化、RDB和AOF混合持久化等持久化策略。

Redis以下几种持久性选项范围：

• RDB持久性按指定的时间间隔执行数据集的时间点快照。

• AOF持久性会记录服务器接收的每个写入操作，这些操作将在服务器启动时再次播放，以重建原始数据集。使用与Redis协议本身相同的格式记录命令，并且采用仅追加方式。当日志太大时，Redis可以在后台重写日志。

• 可以在同一实例中同时合并AOF和RDB。在这种情况下，当Redis重新启动时，AOF文件将用于重建原始数据集，因为它可以保证是最完整的。

• 如果希望只用作缓存服务器，对数据的持久性无要求，也可以完全禁用持久性。

下面着重介绍RDB和AOF持久化的特点和应用场景。

RDB持久化

RDB持久化的优点

RDB 是 Redis 默认的持久化方案。在指定的时间间隔内，写操作达到指定的次数，则会将内存中的数据写入到磁盘RDB文件中。由于RDB文件是一个非常紧凑的文件，比较容易备份，所以RDB对于灾难恢复非常有用。RDB最大限度地提高了Redis的性能，因为Redis父进程的持久化操作是通过分叉子进程实现，而父进程不会执行磁盘I / O等操作。与AOF相比，RDB允许大型数据集更快地重启。

RDB持久化的缺点

RDB持久化的写入方式决定了该持久化策略并不能完全保证数据的安全性。RDB需要经常使用fork（）才能使用子进程将其持久化在磁盘上。如果数据集很大，Fork（）可能很耗时，并且如果数据集很大且CPU性能不佳，则可能导致Redis停止为客户端服务几毫秒甚至一秒钟。该过程如果出现宕机，则可能造成数据丢失。

RDB持久化配置

打开 redis.conf 文件，定位到 SNAPSHOTTING 对应内容

save <seconds> <changes>

# save ""

save 900 1

save 300 10

save 60 10000

dbfilename dump.rdb

dir ./

rdbcompression yes

save <指定时间间隔> <执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是 900秒内有1个更改，300秒内有10个更改以及60秒内有10000个更改，则将内存中的数据快照写入磁盘。关闭RDB，则把上面配置注释即可。

• dbfilename指定本地数据库文件名，默认文件名为 dump.rdb，文件格式.rdb结尾。

• dir指定数据库存放目录为当前目录

• rdbcompression开启数据压缩，默认为yes，Redis采用LZF压缩方式。

RDB的触发与恢复

触发RDB快照的方式有save策略触发，flush命令（清空数据库所有数据），shutdown（关闭redis）命令，三种方式都是调用redis的bgsave机制实现快照触发。

RDB文件恢复数据的方式是将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。

AOF持久化

AOF持久化的优势

AOF可以弥补RDB的不足（数据的不一致性），它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

使用AOF Redis更加持久，提供不同的fsync策略：完全没有fsync，每秒fsync，每个查询fsync。使用默认策略fsync时，每秒的写入性能仍然很好（fsync是使用后台线程执行的，并且在没有进行fsync的情况下，主线程将尽力执行写入操作。）

AOF日志是仅追加的日志，因此即便是断电故障，也不会出现磁盘寻道或损坏问题。即使由于某种原因（磁盘已满或其他）导致日志错误，也可以使用redis-check-aof工具=轻松修复。

AOF持久化的缺点

对于同一数据集，AOF文件通常大于等效的RDB文件。在特定的fsync策略下，AOF比RDB的效率低。通常，在将fsync设置为每秒的情况下，性能仍然很高，并且在禁用fsync的情况下，即使在高负载下，它也应与RDB一样快。即使在巨大的写负载的情况下，RDB仍然能够提供有关最大延迟的更多保证。但是如果fsync策略为aways，则随着集群负载增大，AOF记录的内容越来越大多，文件会越来越大，数据恢复也会越来越慢。

AOF持久化配置

打开 redis.conf 文件，定位到APPEND ONLY MODE 对应内容

appendonly yes

appendfilename "appendonly.aof"

appendfsync everysec

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

说明：

• appendonly 配置redis 默认关闭，开启需要手动把no改为yes
• appendfilename指定本地数据库文件名，默认值为 appendonly.aof
• appendfsync everysec指定更新日志条件为每秒更新，共三种策略（aways，everyse，no）
• auto-aof-rewrite-min-size配置重写触发机制，当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

AOF触发与恢复

AOF主要根据配置文件策略触发，可以是每次执行触发，可以是每秒触发，可以不同步。

AOF的恢复主要是将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复

AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以Redis 新增了重写机制，通过auto-aof-rewrite-min-size控制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。

作者：张文博

其他讨论

4大步骤节省30%浪费，优化企业上云成本从了解云开始！

运维思考 | 你知道CMDB与监控是什么关系吗？

【干货】4种Oracle DBaaS部署模式，你在使用哪一种？

如何改善监控问题，试试打造企业统一监控平台体系！

云计算 | 数据在云上安全吗？DDoS攻击怎么办？