Redis 持久化

Redis 持久化：Redis 将内存中的数据写入到磁盘，永久保存 。

持久化的模式

RDB（Redis DataBase）模式

AOF（Append Only File）模式

RDB 持久化

可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）

1.默认情况下，Redis保存数据集快照到磁盘，名为 dump.rdb 的二进制文件。你可以设置让 Redis 在 N秒内至少有M次数据集改动时保存数据集，或者你也可以手动调用 SAVE 或者 BGSAVE 命令。

2.在上文中我们已经在配置文件中做过对应的配置：
例如，这个配置会让 Redis 在每个 60 秒内至少有 1000 次键改动时自动转储数据集到磁盘：
save 60 1000

3.当 Redis 需要保存 dump.rdb 文件时，服务器执行以下操作：
Redis 调用 fork() ，同时拥有父进程和子进程。
子进程将数据集写入到一个临时的 RDB 文件中。当子进程完成对新 RDB 文件的写入时， Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

4.这种方式使得 Redis 可以从写时复制机制中获益。

RDB 持久化配置

# 编辑配置文件
[root@redis ~]# vim /service/redis/6379/redis.conf 
bind 172.16.1.51 127.0.0.1
port 6379
daemonize yes
pidfile /service/redis/6379/redis_6379.pid
loglevel notice
logfile /service/redis/6379/redis_6379.log
# 设置 redis 密码
requirepass 123
# 持久化数据文件存储位置
dir /service/redis/6379
# rdb持久化数据文件名
dbfilename dump.rdb
# 900秒（15分钟）内有1个更改
save 900 1
# 300秒（5分钟）内有10个更改
save 300 10
# 60秒（1分钟）内有10000个更改
save 60 10000

RDB 文件位置（及使用）

# RDB 文件
[root@redis 6379]# ll
-rw-r--r-- 1 root root   223 Aug  4 09:17 dump.rdb

# 使用 RDB 文件步骤，如果先走第 2 步， RDB 文件会被覆盖
1.先停止 Redis
2.将 RDB 文件 放到指定目录下
3.启动 Redis

RDB 持久化优缺点

RDB 持久化优点

1.RDB 是一种表示某个即时点的 Redis 数据的紧凑文件。RDB 文件适合用于备份。例如，你可能想要每小时归档最近24小时的 RDB 文件，每天保存近30天的 RDB 快照，这允许你很容易的恢复不同版本的数据集以容灾 。

2.RDB 非常适合于灾难恢复，作为一个紧凑的单一文件，可以被传输到远程的数据中心 。

3.RDB 最大化 了Redis 的性能，因为 Redis 父进程持久化时唯一需要做的是调用一个子进程，由子进程完成所有剩余工作，父进程实例不需要执行像磁盘 I/O 这样的操作，

4.RDB 在重启保存了大量数据集的实例时，比 AOF 要快 。

RDB 持久化缺点

1.当你需要在 Redis 停止工作（例如停电）时最小化数据丢失，RDB可能不太好。你可以配置不同的保存点（save point）来保存RDB文件；然而，你通常每隔5分钟或更久创建一个RDB快照，所以一旦Redis因为任何原因没有正确关闭而停止工作，你就得做好最近几分钟数据丢失的准备了。

2.RDB 需要经常 fork() 子进程来持久化到磁盘。如果数据集很大的话，fork() 比较耗时，结果就是，当数据集非常大并且CPU性能不够强大的话，Redis 会停止服务客户端几毫秒甚至一秒。AOF也需要 fork()，但是你可以调整多久频率重写日志而不会有损（trade-off）持久性（durability）。

RDB 持久化优缺点总结

优点：速度快，适合于用作备份，主从复制也是基于 RDB 持久化功能实现的

缺点：会有数据丢失、导致服务停止几秒

AOF 持久化

AOF（append only file）只追加文件，记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾 。

AOF 持久化配置

# 修改配置文件
[root@redis redis]# vim /service/redis/6379/redis.conf
# 是否打开AOF日志功能
appendonly yes/no
# 每一条命令都立即同步到 AOF
appendfsync always
# 每秒写一次
appendfsync everysec
# 写入工作交给操作系统，由操作系统判断缓冲区大小，统一写入到 AOF（不用）
appendfsync no

AOF 文件位置（及使用）

[root@dbtest01 6379]# ll
-rw-r--r-- 1 root root  9868 Aug  4 12:32 appendonly.aof

# AOF 文件中，每一个 * 号，代表 Redis 中一次数据操作
[root@dbtest01 6379]# redis-cli -a 12345
127.0.0.1:6379> set wqh zzz
OK
[root@dbtest01 6379]# tail appendonly.aof
...
*3
$3
set
$3
wqh
$3
zzz

# 如果执行了 FLUSHALL 清空了所有的数据，编辑 AOF文件，删除下面的几行，重新启动 Redis 即可
[root@dbtest01 6379]# vim appendonly.aof
*1
$8
FLUSHALL

# 重启，就可以恢复 AOF文件日志中 FLUSHALL 之前所有的数据
[root@dbtest01 6379]# redis-cli  -a 12345 shutdown
[root@dbtest01 6379]# !redis-ser
redis-server /service/redis/6379/redis.conf

AOF 持久化优缺点

AOF 持久化优点

1.使用AOF Redis 会更具有可持久性（durable）：你可以有很多不同的fsync策略：没有fsync，每秒fsync，每次请求时fsync。使用默认的每秒fsync策略，写性能也仍然很不错（fsync是由后台线程完成的，主线程继续努力地执行写请求），即便宕机，你也就仅仅只损失一秒钟的写数据。

2.AOF日志是一个追加文件，所以不需要定位，在断电时也没有损坏问题。即使由于某种原因文件末尾是一个写到一半的命令（磁盘满或者其他原因），redis-check-aof工具也可以很轻易的修复。

3.当AOF文件变得很大时，Redis会自动在后台进行重写。重写是绝对安全的，因为Redis继续往旧的文件中追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦第二个文件创建完毕，Redis就会切换这两个文件，并开始往新文件追加。

4.AOF文件里面包含一个接一个的操作，以易于理解和解析的格式存储。你也可以轻易的导出一个AOF文件。例如，即使你不小心错误地使用 FLUSHALL 命令清空一切，如果此时并没有执行重写，你仍然可以保存你的数据集，你只要停止服务器，删除最后一条命令，然后重启 Redis 就可以 。

注意： AOF 恢复数据与 RDB 不同，RDB 模式恢复数据需要先停止服务，再迁移 RDB 文件（否则会被覆盖），AOF 不需要；RDB 是覆盖的，AOF 是追加的 。

AOF 持久化缺点

1.磁盘容量，对同样的数据集，AOF文件通常要大于等价的RDB文件 。

2.备份速度，AOF 可能比 RDB 慢，这取决于准确的 fsync 策略。通常 fsync 设置为每秒一次的话性能仍然很高，如果关闭fsync，即使在很高的负载下也和RDB一样的快。不过，即使在很大的写负载情况下，RDB还是能提供能好的最大延迟保证。

AOF 持久化优缺点总结

优点：可以最大程度保证数据不丢失

缺点：日志记录量级比较大

AOF 重写功能

1.因为 AOF 的运作方式是不断地将命令追加到文件的末尾，所以随着写入命令的不断增加， AOF 文件的体积也变得越来越大。举个例子，如果你对一个计数器调用了 100 次 INCR ，那么仅仅是为了保存这个计数器的当前值， AOF 文件就需要使用 100 条记录。然而在实际上，只使用一条 SET 命令已经足以保存计数器的当前值了，其余 99 条记录实际上都是多余的。

2.为了处理这种情况， Redis 支持一种有趣的特性：可以在不断服务客户端的情况下，对 AOF 文件进行重建。执行 BGREWRITEAOF 命令， Redis 将生产一个新的 AOF 文件，这个文件包含重建当前数据集所需的最少命令。

RDB 与 AOF 持久化对比

RDB 与 AOF 如何选择

一般来说，如果想达到足以媲美 PostgreSQL 的数据安全性，你应该同时使用两种持久化功能

如果你非常关心你的数据，但仍然可以承受数分钟以内的数据丢失，那么你 可以只使用 RDB 持久化

• 避免单独使用 AOF 持久化，有很多用户单独使用AOF，但是我们并不鼓励这样，因为时常进行RDB快照非常方便于数据库备份，启动速度也比较快，还避免了 AOF 引擎的 Bug
• 个人感触：在企业中，通常都使用 RDB 来做持久化，因为一般 Redis 是在做 MySQL 的缓存，就算缓存数据丢失，真实的数据还是在 MySQL 中，用缓存是为了读数据的速度，性能而考虑，所以还是建议使用 RDB 持久化，相对来说会好一些
• 除非专门用 Redis 来做一个 Key：Value 的数据库，而且数据很重要，那么可以考虑使用 AOF 持久化

RDB 与 AOF 相互作用

在版本号大于等于 2.4 的 Redis 中， BGSAVE 执行的过程中， 不可以执行 BGREWRITEAOF 。 反过来说， 在 BGREWRITEAOF 执行的过程中， 也不可以执行 BGSAVE。这可以防止两个 Redis 后台进程同时对磁盘进行大量的 I/O 操作 。

如果 BGSAVE 正在执行， 并且用户显示地调用 BGREWRITEAOF 命令， 那么服务器将向用户回复一个 OK 状态， 并告知用户， BGREWRITEAOF 已经被预定执行： 一旦 BGSAVE 执行完毕， BGREWRITEAOF 就会正式开始。 当 Redis 启动时， 如果 RDB 持久化和 AOF 持久化都被打开了， 那么程序会优先使用 AOF 文件来恢复数据集， 因为 AOF 文件所保存的数据通常是最完整的 。

备份 Redis 数据（RBD）

1.Redis 对于数据备份是非常友好的，因为你可以在服务器运行的时候对 RDB 文件进行复制： RDB 文件一旦被创建，就不会进行任何修改，只会重新生成覆盖 。

2.当服务器要创建一个新的 RDB 文件时，它先将文件的内容保存在一个临时文件里面，当临时文件写入完毕时，程序才使用临时文件替换原来的 RDB 文件 。

3.这也就是说，无论何时， 复制 RDB 文件都是绝对安全的 。

以下是备份建议：
创建一个定期任务（Crond）， 每小时将一个 RDB 文件备份到一个文件夹， 并且每天将一个 RDB 文件备份到另一个文件夹；
确保快照的备份都带有相应的日期和时间信息， 每次执行定期任务脚本时， 使用 find 命令来删除过期的快照： 比如说， 你可以保留最近 48 小时内的每小时快照， 还可以保留最近一两个月的每日快照；

至少每天一次， 将 RDB 备份到你的数据中心之外， 或者至少是备份到你运行 Redis 服务器的物理机器之外 。

RDB 持久化高级配置

#编辑配置文件
[root@redis redis]# vim /etc/redis/6379/redis.conf
#后台备份进程出错时，主进程停不停止写入? 主进程不停止容易造成数据不一致
stop-writes-on-bgsave-error yes
#导出的rdb文件是否压缩 如果rdb的大小很大的话建议这么做
rdbcompression yes
#导入rbd恢复时数据时，要不要检验rdb的完整性 验证版本是不是一致
rdbchecksum yes

AOF 持久化高级配置

#编辑配置文件
[root@redis redis]# vim /etc/redis/6379/redis.conf
#正在导出rdb快照的过程中，要不要停止同步aof
no-appendfsync-on-rewrite yes
#aof文件大小比起上次重写时的大小，增长率100%时重写，缺点:业务开始的时候，会重复重写多次
auto-aof-rewrite-percentage 100
#aof文件,至少超过64M时,重写
auto-aof-rewrite-min-size 64mb