Redis持久化锦囊在手，再也不会担心数据丢失了

Redis 的读写都是在内存中进行的，所以它的性能高。而当我们的服务器断开或者重启的时候，数据就会消失，那么我们该怎么解决这个问题呢？

其实 Redis 已经为我们提供了一种持久化的机制，分别是 RDB 和 AOF 两种方式，接下来跟着我一起看看这两个锦囊都是怎么保证数据的持久化的。

持久化

由于 Redis 是基于内存的数据库，所以当服务器出现故障的时候，我们的数据就得不到安全保障。

这个时候就需要将内存中的数据存储到磁盘中，当我们服务器重启时，便可以通过磁盘来恢复数据，这个过程就叫做 Redis 持久化。

RDB

简介

RDB全称Redis Database Backup file（Redis数据备份文件），也可以称为Redis数据快照。

• RDB 文件是一个经过压缩的二进制文件（默认：dump.rdb）；
• RDB 文件保存在硬盘里；
• 通过保存数据库中的键值对来记录数据库状态。

创建

SAVE

def SAVE():
    # 创建 RDB 文件
    rdbSave()

BGSAVE

def BGSAVE():
    # 创建子进程
    pid = fork()

    if pid == 0:
        # 子进程负责创建 RDB 文件
        rdbSave()
        # 完成之后向父进程发送信号
        signal_parent()
    elif pid > 0:
        # 父进程继续处理命令请求，并通过轮训等待子进程的信号
        handle_request_and_wait_signal()
    else:
        handle_fork_error()

载入

主要设置

设置保存条件

save 900 1
save 300 10

• 服务器在 900 秒之内，对数据库进行了至少 1 次修改了；
• 服务器在 300 秒之内，对数据库进行了至少 10 次修改。

saveparams

• saveparams 属性是一个数组；
• 数组中的每一个元素都是一个 saveparam 结构；
• 每个 saveparam 结构都保存了一个 save 选项设置的保存条件。

struct saveparam {
    // 秒数
    time_t seconds;
    // 修改数
    int changes;
}

dirty

lastsave

检查保存条件是否满足

def serverCron():
    # ....
    # 遍历所有保存条件
    for saveparam in server.saveparams:
        # 计算距离上次执行保存操作有多少秒
        save_interval = unixtime_now() - server.lastsave

        # 如果数据库状态的修改次数超过条件所设置的次数
        # 如果距离上次保存的时间超过条件所设置的时间
        if server.dirty >= saveparam.changes and save_interval > saveparam.seconds:
            BGSAVE()

默认配置

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#在给定的秒数和给定的对数据库的写操作数下，自动持久化操作。
#   save <seconds> <changes>
# 
save 900 1
save 300 10
save 60 10000

#bgsave发生错误时是否停止写入，一般为yes
stop-writes-on-bgsave-error yes

#持久化时是否使用LZF压缩字符串对象?
rdbcompression yes

#是否对rdb文件进行校验和检验，通常为yes
rdbchecksum yes

# RDB持久化文件名
dbfilename dump.rdb

#持久化文件存储目录
dir ./

AOF

简介

• 通过保存 Redis 服务器所执行的写命令来记录数据库状态；
• 写入 AOF 文件的所有命令都是以 Redis 的命令请求协议格式保存的。

实现

命令追加

文件同步

• WRITE：根据条件，将 aof_buf 中的缓存写入到 AOF 文件；
• SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。

Always

everysec

no

数据加载

1. 创建一个不带网络连接的伪客户端；
2. 从 AOF 文件中分析并读取出一条写命令；
3. 使用伪客户端执行被读出的写命令；
4. 一直执行步骤 2 和 3，直到 AOF 文件中的所有写命令都被处理完毕为止。

文件重写

• 为了解决 AOF 文件体积膨胀的问题；
• 通过重写创建一个新的 AOF 文件来替代现有的 AOF 文件，新的 AOF 文件不会包含任何浪费空间的冗余命令。

实现

• 不需要对现有的 AOF 文件进行任何操作；
• 从数据库中直接读取键现在的值；
• 用一条命令记录键值对，从而代替之前记录这个键值对的多条命令。

后台重写

1. 执行客户端发来的命令；
2. 将执行后的写命令追加到 AOF 缓冲区；
3. 将执行后的写命令追加到 AOF 重写缓冲区。

默认配置

############################## APPEND ONLY MODE ###############################

#开启AOF持久化方式
appendonly no

#AOF持久化文件名
appendfilename "appendonly.aof"
#每秒把缓冲区的数据fsync到磁盘
appendfsync everysec
# appendfsync no
#是否在执行重写时不同步数据到AOF文件
no-appendfsync-on-rewrite no

# 触发AOF文件执行重写的增长率
auto-aof-rewrite-percentage 100
#触发AOF文件执行重写的最小size
auto-aof-rewrite-min-size 64mb

#redis在恢复时，会忽略最后一条可能存在问题的指令
aof-load-truncated yes

#是否打开混合开关
aof-use-rdb-preamble yes

总结

• 对于大中型的应用，我们既想保证数据完整性又想保证高效率，就应该结合使用 RDB 和 AOF 两种方式；
• 如果只是需要保证数据的完整性，保护数据不会丢失，那么优先使用 AOF 方式；
• 如果是处理大规模的数据恢复，追求更高更快的效率的话，优先使用 RDB 方式。