Redis持久化

redis是内存数据库，如果不将内存中的数据库状态保存到磁盘上，呢么一旦服务器进程退出，服务器中的数据库状态也会消失，所以redis提供了持久化功能

零基础可以先这样理解：

Redis 快是因为主要在内存里读写；持久化是为了宕机后能从磁盘恢复数据。

Redis 常见持久化方式有两种：RDB 保存某个时间点的完整快照，AOF 记录每一次写命令。生产环境经常两者一起开，用 RDB 提高恢复速度，用 AOF 降低数据丢失窗口。

持久化原理图

flowchart TD
    A["客户端写入 Redis"] --> B["内存数据变化"]
    B --> C{"持久化方式"}
    C -- "RDB" --> D["fork 子进程"]
    D --> E["生成内存快照 dump.rdb"]
    C -- "AOF" --> F["追加写命令到 appendonly.aof"]
    F --> G{"是否触发 AOF 重写"}
    G -- "是" --> H["生成更短的新 AOF 文件"]
    G -- "否" --> I["继续追加日志"]
    J["Redis 重启"] --> K{"优先读取持久化文件"}
    K --> L["恢复内存数据"]

RDB 像“拍照片”，恢复快但可能丢失最近一次快照后的数据；AOF 像“记流水账”，数据更完整但文件可能更大，恢复时要重放命令。

RDB(Redis DataBase)

什么是RDB RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。 也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中 默认的文件名为dump.rdb,恢复时是将快照文件直接读到内存里 redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那么RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据库可能丢失。

触发机制

#   save ""
save 900 1
save 300 10
save 60 10000

1. save规则满足的情况下，会自动触发rdb规则
2. 执行flushall也会触发rdb规则
3. 退出redis,也会产生rdb文件 备份就会自动生成一个dump.rdb

如何恢复rdb文件

1. 只需要将rdb文件放在我们redis启动目录就可以了，redis启动时就会自动检查dump.rdb恢复其中的数据
2. 查看需要存在的位置，如果这个目录下存在dump.rdb文件，启动就会自动恢复其中的数据
3. 适合大规模的数据恢复
4. 对数据完整性要求不高
5. 需要一定的时间间隔进行操作，如果redis意外宕机，这个最后一次修改的数据就没有了
6. fork进程运行的时候需要占用一定的内存空间

AOF（Append Only File）

将我们的所有命令都记录下来，恢复的时候就把这个文件全部执行一遍

什么是aof 以日志的形式来记录每个写操作，将redis执行过的所有指令记录下来（读操作不记录），只需追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据库，换言之，redis重启的话就根据日志wen'jian的内容将写指令从前到后执行一次以完成数据的恢复工作。 AOF保存的是 appendonly.aof文件

# Please check http://redis.io/topics/persistence for more information.
appendonly no	#默认是不开启的，如果开启AOF改为yes即可
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"	#默认文件名

如果aof文件有错误，这时候redis是启动不起来的，我们需要修复aof文件 redis提供了一个一个工具，redis-check-aop --fix 如果文件正常，重启就可以恢复了！

重写规则说明

默认的是文件的无限追加，文件会越来越大

# If you have latency problems turn this to "yes". Otherwise leave it as
# "no" that is the safest pick from the point of view of durability.

no-appendfsync-on-rewrite no

# Automatic rewrite of the append only file.
# Redis is able to automatically rewrite the log file implicitly calling
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
#
# This is how it works: Redis remembers the size of the AOF file after the
# latest rewrite (if no rewrite has happened since the restart, the size of
# the AOF at startup is used).
#
# This base size is compared to the current size. If the current size is
# bigger than the specified percentage, the rewrite is triggered. Also
# you need to specify a minimal size for the AOF file to be rewritten, this
# is useful to avoid rewriting the AOF file even if the percentage increase
# is reached but it is still pretty small.
#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb


#如果aof文件大于64mb，就会fork一个进程来将我们的文件进行重写

aof优点缺点

优点：

1. 每一次修改都同步，文件完整性会更好
2. 每秒同步一次，可能会丢失一秒数据
3. 从不同步，效率最高

缺点：

1. 相对于数据文件来说，aof远大于rdb,修复的速度也比rdb慢
2. aof运行效率比rdb慢所以redis默认配置是rdb持久化

选择建议

场景	推荐配置	原因
缓存数据，可接受丢失	只开 RDB 或不开持久化	重启后可从数据库重新加载
重要业务数据	RDB + AOF	兼顾恢复速度和数据完整性
写入量很大	关注 AOF 重写和磁盘 IO	防止 AOF 文件过大、fsync 抖动
极端不能丢数据	Redis 不应单独承担最终存储	需要数据库、复制、备份一起保障