防止数据丢失的最佳实践：RDB与AOF配置

Redis持久化很容易被误解，因为Redis感觉像数据库，但行为上首先像内存。如果你在没有持久化的情况下重启它，数据就会丢失。如果启用了持久化但调整不当，你仍然可能丢失最近的写入，在磁盘压力期间阻塞客户端，或者在故障期间发现数据的唯一副本与Redis进程位于同一个故障卷上。

正确的Redis数据丢失策略始于一个诚实的问题：如果最后几秒、几分钟或几小时的写入消失会发生什么？产品页面的缓存通常可以重建。会话存储可能会让用户烦恼，但不会摧毁业务。队列、速率限制账本、购物车存储或功能标志存储可能需要更严格的持久性。RDB和AOF是Redis提供的两种工具，它们解决了这个问题的不同部分。

理解Redis持久化机制

Redis有两种主要的持久化模式：

RDB快照

RDB将数据集的时间点快照写入磁盘，通常为dump.rdb。Redis fork一个子进程，子进程序列化数据集，父进程继续服务客户端。这使得RDB对于备份、副本和快速重启非常有用，但它有一个明显的权衡：如果进程或主机故障，在最后一次成功快照之后写入的任何内容都可能丢失。

典型的RDB设置如下：

save 900 1       # 15分钟内至少1个键改变则保存
save 300 10      # 5分钟内至少10个键改变则保存
save 60 10000    # 1分钟内至少10000个键改变则保存
dbfilename dump.rdb
dir /var/lib/redis

这些save行并不是Redis会严格按照该时间表保存的承诺。它们是触发规则：如果在间隔期间有足够多的键改变，Redis会启动后台保存。如果磁盘慢、数据集大或主机内存不足，后台保存可能会失败，或者通过fork和写时复制压力产生延迟。

当你想要紧凑的快照和快速恢复行为时，RDB最强。当你对近期数据丢失的容忍度低时，它最弱。

AOF日志

AOF，即追加文件持久化，记录写命令，以便Redis可以在重启时重放它们。它通常比RDB提供更好的持久性，因为它可以比快照计划更频繁地刷新写入。权衡是更多的磁盘I/O、重写前更大的文件，以及如果Redis必须重放大量日志，启动速度可能较慢。

核心设置是：

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb
aof-rewrite-incremental-fsync yes

重要的行是appendfsync。使用everysec，Redis要求操作系统大约每秒刷新一次AOF。在正常的Redis进程崩溃中，这通常将丢失限制在最近大约一秒的写入。在完全主机崩溃或存储故障中，确切的丢失取决于操作系统、文件系统、磁盘缓存和存储行为，所以不要将其描述为数学上的保证。

appendfsync always在每次写入后刷新，成本更高。它可能适用于写入量适中的小型关键Redis部署，但在实际流量下可能会严重损害延迟。appendfsync no让操作系统决定何时刷新；它很快，但给你一个更宽且更不可预测的丢失窗口。

防止数据丢失的最佳实践

仅当你理解Redis将加载哪个文件时才同时使用两者

许多生产Redis部署同时启用RDB和AOF。当Redis存储的数据重建起来会很痛苦时，这是一个合理的默认设置。RDB给你紧凑的备份工件。AOF给你一个更小的近期丢失窗口。

使用如下配置：

save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

在恢复期间有一个细节很重要：当AOF启用时，Redis通常在启动时加载AOF数据，因为它预计比RDB快照更完整。不要假设Redis会先加载RDB然后回退到AOF。测试你的Redis版本和部署布局的恢复路径，特别是对于使用较新多部分AOF格式的Redis版本。

从丢失窗口向后选择`appendfsync`

从业务影响开始，而不是Redis设置。

如果Redis是一个可丢弃的缓存，仅RDB可能就足够了，甚至如果应用程序安全地重新填充，也可以没有持久化。如果Redis包含会话，appendfsync everysec通常是一个实用的平衡。如果Redis是工作流的一部分，其中丢失已确认的写入会造成真正的业务损害，那么仅Redis持久化可能不是正确的持久性边界。你可能需要一个主数据库、一个持久队列或Redis之外的应用程序级预写日志行为。

对于大多数操作性的Redis使用，从以下开始：

appendonly yes
appendfsync everysec

然后观察延迟、磁盘写入时间、AOF重写行为和重启时间，然后再决定是转向always还是远离AOF。

保留RDB快照，但不要过于激进

频繁的RDB保存减少了快照之间丢失的数据量，但也增加了fork频率。fork一个大的Redis进程可能很昂贵，并且在子进程保存期间的写入会造成写时复制内存压力。如果你的Redis实例有40 GB数据集且写入率很高，每分钟保存可能会造成更差的可靠性，因为主机在内存和磁盘压力下花费太多时间。

合理的RDB保存规则取决于写入率和恢复期望。小型缓存可以频繁快照而不会出现问题。大型会话存储可能需要较少的RDB快照加上AOF以获得近期持久性。在BGSAVE期间观察INFO persistence、Redis日志和主机内存，而不仅仅是Redis配置文件。

将AOF重写视为正常维护，而不是紧急情况

AOF文件因为记录写入而增长。Redis在后台将它们重写为紧凑表示。默认值通常是一个不错的起点：

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

这意味着Redis在AOF与上次重写后的大小相比显著增长时考虑重写，前提是它至少达到最小大小。如果重写不断发生，增加最小大小或调查嘈杂的写入模式。如果AOF长时间没有重写而增长，检查日志、磁盘空间和INFO persistence。

你可以手动触发重写：

redis-cli BGREWRITEAOF

如果可能，在安静时段执行此操作。重写比让文件无限增长更安全，但它仍然消耗CPU、磁盘带宽和写时复制内存。

将持久化文件备份到其他地方

持久化不是备份。同一主机上的持久化文件保护你免受Redis进程重启的影响。它们不能保护你免受磁盘丢失、意外删除、覆盖数据目录的错误部署或运行FLUSHALL的操作员错误。

将RDB和AOF文件复制到单独的存储。如果你使用文件系统快照或云卷快照，在单独的实例上测试恢复。对于RDB副本，优先复制已完成的快照文件而不是正在写入的文件。对于AOF，在基于文件名构建备份脚本之前，了解你的Redis版本的文件布局。

监控预示数据丢失的信号

在事件期间有用的命令是：

redis-cli INFO persistence

查找失败的后台保存、AOF重写状态、最后保存时间和延迟的fsync指示器。将其与主机指标配对：磁盘延迟、可用磁盘空间、内存余量和内核OOM事件。如果BGSAVE失败数小时而没有人注意到，Redis配置可能看起来安全，而实际恢复点越来越旧。

使用复制或Sentinel实现可用性，而不是作为唯一的备份

副本、Redis Sentinel和Redis Cluster有助于可用性。它们不会自动解决每个数据丢失问题。错误的写入、意外删除或应用程序错误可以快速复制。如果存在复制延迟，故障转移也可能提升一个缺少最近写入的副本。在设计中保留持久化、备份和恢复测试。

对于许多团队来说，实际的设置是使用appendfsync everysec的AOF、合理节奏的RDB快照、外部备份、持久化失败监控以及经过测试的恢复运行手册。Redis在这种形式下可以是可靠的，但只有当你将持久化视为一个操作性的系统而不是一个复选框时。