Redis的两种持久化方案
Redis 提供了多种持久化机制来保证数据在发生意外情况下（如断电或服务器崩溃）不丢失。以下是几种主要的 Redis 持久化方案及其特点：
1. RDB (Redis Database Backup)
RDB 是 Redis 创建的数据库快照，它可以将数据集快照以二进制文件的形式存储在磁盘上。RDB 文件可以在指定时间间隔创建，也可以通过命令手动触发。
特点：
- 性能：生成 RDB 文件的过程不会影响 Redis 的性能，因为 Redis fork 出一个子进程来完成快照的创建，主进程依然处理客户端请求。
- 数据恢复：RDB 文件非常适合大型数据集的备份和数据恢复。加载 RDB 文件时速度非常快。
- 配置灵活：通过配置
save选项，可以在一定的写命令数量或时间间隔后自动生成 RDB 文件。
配置：
# 在 `redis.conf` 文件中配置 RDB 选项
save 900 1 # 900秒内至少有1个键被修改，则触发RDB持久化
save 300 10 # 300秒内至少有10个键被修改，则触发RDB持久化
save 60 10000 # 60秒内至少有10000个键被修改，则触发RDB持久化
dbfilename dump.rdb # 指定RDB文件名
dir /var/lib/redis # 指定RDB文件存放路径
手动触发：
# 生成 RDB 文件
SAVE # 同步方式阻塞Redis
BGSAVE # 异步方式，不阻塞Redis
2. AOF (Append-Only File)
AOF 方式通过将每个写操作都记录在一个日志文件中来实现持久化。通过回放这个 AOF 日志文件，可以重建数据集。
特点：
- 实时性：AOF 以追加方式写入文件，数据恢复的即时性非常高。
- 数据安全：可以通过配置
fsync策略保证数据的持久化频率，如fsync每秒一次、每次写操作都fsync、或不执行fsync（交由操作系统管理）。 - 文件管理：AOF 文件随着写操作的增加而不断增大，但 Redis 提供了 AOF 重写机制来压缩文件大小。
配置：
# 在 `redis.conf` 文件中配置 AOF 选项
appendonly yes # 开启AOF持久化
appendfilename "appendonly.aof" # AOF文件名
# fsync选项
# always: 每次写入操作都fsync，最安全但最慢
# everysec: 每秒fsync一次，折中方案
# no: 不执行fsync，由操作系统决定什么时候将数据写入磁盘
appendfsync everysec
# AOF 重写配置
auto-aof-rewrite-percentage 100 # AOF文件大小增长了上一次重写时大小的百分比
auto-aof-rewrite-min-size 64mb # AOF文件最小大小
手动触发：
# 手动触发 AOF 重写
BGREWRITEAOF
3. 混合持久化
从 Redis 4.0 开始，支持 RDB 和 AOF 两者结合的混合持久化方式。这种方式在AOF重写时，将新的AOF文件开头保存为一个RDB格式的二进制快照，后面再追加增量的AOF日志指令。这种持久化方案结合了RDB文件的重启加载速度快与AOF日志文件的实时性。
配置：
aof-use-rdb-preamble yes # 开启AOF文件混合模式
4. No Persistence
如果你对性能有极高的要求，并且不在意数据持久化（例如数据可以通过外部数据库重建），可以完全关闭持久化。
配置：
# 关闭 RDB 和 AOF 持久化
save ""
appendonly no
选择适合的持久化方案
选择合适的 Redis 持久化方案需要考虑以下因素：
- 数据重要性：数据丢失的容忍度是多少？
- 写操作负载：写操作频繁程度如何？是否需要即时持久化？
- 性能要求：对读写性能的要求是什么？
- 存储空间：是否需要节省存储空间？
- 恢复速度：希望在恢复数据时多快能重新上线？
通常，组合使用 RDB 和 AOF 是一种较为推荐的方案，可以兼顾数据持久性和性能。具体配置可以根据业务需求进行调整。例如可以使用 everysec 的 AOF 同步策略，以及定期的 RDB 快照来确保数据的完整性和恢复速度。
每种持久化方案有其优缺点，你们可以根据自身的业务需求和资源来制定最合适的持久化策略以确保数据安全和高效运行。
原文地址：https://blog.csdn.net/qq_40592590/article/details/140146757
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！