Redis持久化

Redis有两种持久化方式，RDB和AOF。

RDB（默认开启）

        RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照后，恢复数据。

        快照默认称为RDB文件，默认是保存在当前运行目录中。

        RDB文件默认名称：dump.rdb

        Redis内部有触发RDB机制，在redis.conf配置文件中，格式如下：

# 900秒内，如果有至少1个key被修改，则执行bgsave
save 900 1
# 300秒内，如果有至少10个key被修改，则执行bgsave
save 300 10
# 禁用RDB
save ""

# 其他配置
# 是否压缩，建议不开启，压缩会消耗cpu
rdbcompression no
# RDB文件名称（在恢复数据时，也会读这个文件名）
dbfilename dump.rdb
# 文件保存的路径目录
dir ./

        执行RDB快照命令：save 或 bgsave

        例：save

        注：该 save 命令是由Redis主进程来执行RDB，会阻塞所有命令。

        Redis在手动停机时会默认执行一次RDB的 save 命令

        例：bgsave

        注：该 bgsave 命令是由Redis子进程来执行RDB，不影响其他请求命令。

        bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入RDB文件。子进程不会影响主进程，但是在fork获取子进程的过程是阻塞的。

        RDB方式 bgsave 的基本流程：

• fork主进程得到一个子进程，共享内存空间（如下图）
• 子进程读取内存数据并写入新的RDB文件
• 用新的RDB文件替换就的RDB文件

        fork采用的是 copy-on-write 技术

• 当主进程执行读操作时，访问共享内存
• 当主进程执行写操作时，则会拷贝一份数据，执行写操作

        RDB的缺点：

• RDB的执行间隔时间长，两次RDB之间写入数据有丢失的风险
• fork子进程、压缩、写出RDB文件都比较耗时

AOF（默认关闭）

        AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看作是命令日志文件。当Redis实例故障重启后，从磁盘读取并执行AOP文件中的每一条命令，恢复数据。

        AOF文件默认名称：appendonly.aof

        AOF相关配置，在redis.conf文件，格式如下：

# 是否开启AOF功能，默认是no，代表是关闭，yes代表是开启
appendonly yes
# AOP文件的名称
appendfilename "appendonly.aof"

# AOF的命令记录的三种频率配置，三选一
# 表示每执行一次写命令，立即记录到AOF文件中
appendfsync always
# 写命令执行完成后先放入AOF缓冲区，然后每隔1秒将缓冲区的数据写到AOF文件中，默认方案
appendfsync everysec
# 写命令执行完成后先放入AOF缓冲区，由操作系统决定何时将缓冲区的数据写到AOF文件
appendfsync no

        AOF的命令记录的三种频率配置对比：

        AOF的缺点：

                因为是记录Redis在运行过程中的所有写命令，所以AOF文件会比RDB文件大很多。并且AOF会记录对同一个key的多次写操作，但实际情况下只有最后一次写操作才有意义。通过执行 bgrewriteaof 命令，可以让AOF文件执行重写功能，用最少的命令达到相同的效果。

                命令如下：（BGREWRITEAOF命令是异步执行）

BGREWRITEAOF

        Redis也会在触发阈值时自动去重写AOF文件。阈值在redis.conf配置文件中：

# AOF文件比上次文件增加超过多少百分比则触发重写（默认配置）
auto-aof-rewrite-percenttage 100
# AOF文件体积最小多大以上才触发重写（默认配置）
auto-aof-rewrite-min-size 64mb

        RDB和AOF的对比：