Redis详解5.数据持久化

章节目录

Redis详解1.安装及使用
Redis详解2.数据结构
Redis详解3.发布订阅
Redis详解4.事务
Redis详解5.数据持久化
Redis详解6.主从模式
Redis详解7.哨兵模式
Redis详解8.Cluster模式

1 简介

为什么需要持久化

由于Redis是基于内存的缓存，一旦系统崩溃那么所有的数据都会丢失，这在生产环境中是不允许的，所以需要把数据持久到硬盘中，以便可以重用数据。

两种持久化方法

Redis提供了两种不同的持久化方法来将数据存储到硬盘里面。这两种持久化方法既可以同时使用，又可以单独使用，在某些情况下甚至可以两种方法都不使用：

1. 快照（snapshotting），它可以将存在于某一时刻的所有数据都写入硬盘里面；
2. 只追加文件（append-only file, AOF)，它会在执行写命令时，将被执行的写命令复制到硬盘里面。

2 快照持久化

Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。在创建快照之后，用户可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务副本，还可以将快照留在原地以便重启服务器时使用。根据配置，快照将被写入dbfilename选项指定的文件里面。如果在新的快照文件创建完毕之，Redis、系统或者硬件这三者之中的任意一个崩溃了，那么Redis将丢失最近一次创建快照之后写入的所有数据。

相关配置

# 指定在多长时间内，有多少次更新操作，就将数据同步到rdb文件
save 900 1
save 300 10
save 60 10000
# 指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
rdbcompression yes
# 指定本地数据库文件名，默认值为dump.rdb
dbfilename dump.rdb
# 指定本地数据库存放目录
dir ./
# 即当bgsave快照操作出错时停止写数据到磁盘
stop-writes-on-bgsave-error no

创建快照

1. 客户端可以通过向Redis发送BGSAVE命令来创建一个快照。Redis会调用fork来创建个子进程，然后子进程负责将快照写入硬盘，而父进程则继续处理命令请求。
2. 客户端还可以通过向Redis发送SAVE命令来创建一个快照，接到SAVE命令的Redis服务器在快照创建完毕之前将不再响应任何其他命令。
3. 如果用户在redis.conf中设置了save配置选项，那么当任意一个save配置选项所设置的条件被满足时，Redis就会触发一次BGSAVE命令。
4. 当Redis通过SHUTDOWN命令接收到关闭服务器的请求时，或者接收到标准TERM信号时，会执行一个SAVE命令，阻塞所有客户端，不再执行客户端发送的任何命令，并在SAVE命令执行完毕之后关闭服务器
5. 当一个Redis服务器连接另一个Redis服务器，并向对方发送SYNC命令来开始一次复制操作的时候，如果主服务器目前没有在执行BGSAVE操作，或者主服务器并非刚刚执行完BGSAVE操作，那么主服务器就会执行 BGSAVE命令。

快照持久化注意事项

由于Redis将丢失最近一次创建快照之后写入的所有数据，如果用户能够妥善地处理快照持久化可能会带来的大量数据丢失，那么快照持久化对用户来说将是一个不错的选择。但对于很多应用程序来说，丢失15分钟、1小时甚至更长时间的数据都是不可接受的，在这种情况下，我们可以使用AOF持久化来将存储在内存里面的数据尽快地保存到硬盘里面。

3 AOF持久化

AOF持久化会将被执行的写命令写到AOF文件的末尾，以此来记录数据发生的变化。因此, Redis只要从头到尾重新执行一次AOF文件包含的所有写命令，就可以恢复AOF文件所记录的数据集。

相关配置

# 指定是否在每次更新操作后进行日志记录，默认为no
appendonly yes
# 指定更新日志条件，共有3个可选值：
# no：表示等操作系统进行数据缓存同步到磁盘（快）
# always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）
# everysec：表示每秒同步一次（折衷，默认值）
appendfsync everysec
# 如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。
# 如果设置为yes，就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞，但是如果这个时候redis挂掉，就会丢失数据。
no-appendfsync-on-rewrite no
# aof文件增长比例，指当前aof文件比上次重写的增长比例大小。
# aof重写即在aof文件在一定大小之后，重新将整个内存写到aof文件当中，以反映最新的状态。
# 这样就避免了，aof文件过大而实际内存数据小的问题（频繁修改数据问题）
auto-aof-rewrite-percentage 100
# 指定触发rewrite的aof文件大小。
# 若aof文件小于该值，即使当前文件的增量比例达到auto-aof-rewrite-percentage的配置值，也不会触发自动rewrite。
# 即这两个配置项同时满足时，才会触发rewrite。
auto-aof-rewrite-min-size 64mb

AOF的缺点

1. 因为Redis会不断地将被执行的写命令记录到AOF文件里面，所以随着 Redis不断运行，AOF文件的体积也会不断增长，在极端情况下，体积不断增大的AOF文件甚至可能会用完硬盘的所有可用空间。
2. 还有另一个问题就是，因为Redis在重启之后需要通过重新执行AOF文件记录的所有写命令来还原数据集，所以如果AOF文件的体积非常大，那么还原操作执行的时间就可能会非常长

AOF注意事项

1. 为了解决AOF文件体积不断增大的问题，用户可以向 Redis发送BGREWRITEAOF命令，这个命令会通过移除AOF文件中的冗余命令来重AOF文件，使AOF文件的体积变得尽可能地小。
2. AOF持久化也可以通过设置auto-aof-rewrite-percentage选项和auto-aof-rewrite-min-size选项来自动执行BGREWRTTEAOF。

4 验证快照和AOF文件

1. 无论是快照持久化还是AOF持久化，都提供了在遇到系统故障时进行数据恢复的工具。 Redis提供了两个命令行程序redis-check-aof和 redis-check-dump，它们可以在系统故障发生之后，检查AOF文件和快照文件的状态，并在有需要的情况下对文件进行修复。
2. 如果用户在运行redis-check-aof程序时给定了--fix参数，那么程序将对AOF文件进行修复。程序修复AOF文件的方法非常简单：它会扫描给定的AOF文件，寻找不正确或者不完整的命令，当发现第一个出错命令的时候，程序会删除出错的命令以及位于出错命令之后的所有命令，只保留那些位于出错命令之前的正确命令。
3. 遗憾的是，目前并没有办法可以修复出错的快照文件。因此，用户最好为重要的快照文件保留多个备份，并在进行数据恢复时，通过计算快照文件的SHA1散列值和SHA256散列值来对内容进行验证。