企业官网建设流程全解析

1. 为什么Redis需要持久化：你丢过数据吗

内存数据库Redis跑得飞快，靠的就是数据全在物理内存里，读写路径上没有磁盘IO的拖累。但这也意味着一个严重隐患：一旦进程退出、服务器宕机或者容器被重新调度，内存里所有数据都会瞬间清零。我见过不少团队，开发环境用Redis当纯缓存，数据丢了无所谓；可一旦上了生产，把登录会话、商品库存、订单状态、限流计数器放进去，才发现重启一次Redis业务直接“失忆”。这时候你才真正意识到，Redis持久化不是可选项，而是必选项。

所谓持久化，就是把内存中的数据以某种格式落盘，进程重启时能够重新加载，尽量恢复到重启前的状态。Redis官方提供了两种方案：RDB快照和AOF日志。两套机制的设计思路完全不同：RDB像是给整个数据集拍一张“定妆照”，某个时间点瞬间全量存盘；AOF则是把每一次写操作都记成一笔日志，重启时按顺序重放这些日志，把数据“重演”回来。理解这个根本差别之后，RDB和AOF各自的优缺点、适用场景、坑在哪里，基本都能推导出来。

这篇文章适合三类人看：刚接触Redis、搞不清两种持久化到底选哪个的初学者；在面试前想把持久化原理讲清楚的求职者；以及已经上线Redis、正在排查数据丢失或想优化备份策略的运维和开发。我会把原理、配置、恢复流程、选型建议和实际踩坑经验串起来讲，争取你读完就能上手操作。

2. 先理解快照型RDB是怎么工作的

RDB是Redis默认开启的持久化方式。它的核心行为，就是在特定的时间点把内存中的全部数据序列化后写入一个二进制文件，默认叫dump.rdb。文件紧凑、恢复速度快，非常适合做全量备份和灾难恢复。但它有一个天然短板：两次快照之间写入的数据，如果此时宕机，这部分会全部丢失。很多所谓“配置了持久化但数据还是丢了”的案例，十有八九是只开了RDB、而且快照间隔设得比较长。

2.1 RDB的触发机制：手动和自动

RDB触发方式有三种。

第一种是手动执行save命令，主进程直接阻塞完成快照。这个命令在数据量大的时候千万慎用，因为save是同步的，期间Redis无法处理任何读写请求。我在本地测试过，一台写入几万key的实例，save命令能卡住几秒钟，线上动不动几十GB数据的话，阻塞时间可能达到分钟级，完全不可接受。

第二种是手动执行bgsave。bgsave会fork出一个子进程来做快照写入，主进程继续对外服务，通常不阻塞。这是日常运维手动备份时最常用的命令。

第三种是自动触发，对应配置文件里的save参数：

# 默认配置一般长这样 save 900 1 # 900秒内至少1次写操作，触发一次bgsave save 300 10 # 300秒内至少10次写操作，触发一次bgsave save 60 10000 # 60秒内至少10000次写操作，触发一次bgsave

这个配置表达的就是“在N秒内发生了M次写操作，就执行一次快照”。条件之间是或的关系，满足任意一条就会触发。把这三条规则翻译成业务语言就是：数据写得不频繁时，拉大快照间隔减少IO开销；数据写得很猛时，快照频率自动提高，降低丢失窗口。初次看这个配置时要有一点意识：它是多个规则取并集，而不是必须同时满足全部条件。

自动触发还有一些隐藏场景，比如主从复制时，从节点执行全量同步会触发主节点bgsave；执行shutdown关闭Redis且持久化开启时，也会先做一次save；还有flushall命令之后，如果你设置了save规则，Redis同样会触发一次快照。这些细节平时不容易注意到，但在排查“为什么磁盘突然多了个rdb文件”时会很有用。

提示：线上环境如果要手艺人话，永远选bgsave而不是save。用save阻塞几秒到几十秒，业务超时可不是闹着玩的。用LASTSAVE命令可以查看最近一次成功生成快照的时间，配合日志快速确认快照是否正常完成。

2.2 快照原理：fork和写时复制

RDB快照能在线完成而不阻塞主进程，靠的是Linux的fork机制和写时复制技术。执行bgsave时，主进程fork出一个子进程。这个fork出来的子进程会拿到父进程内存页表的副本。此时主进程和子进程共享同一份物理内存，子进程负责把这部分内存数据写入临时rdb文件。

真正的精妙之处在于写时复制。快照生成过程中，主进程如果收到新的写请求，需要修改某个内存页，操作系统就会先复制这个内存页给主进程，主进程在副本上修改，而子进程看到的还是原始的内存页。这样快照记录的始终是fork瞬间的数据状态，不会被并发写入污染。

这个机制也带来了运维上最重要的启发：写时复制意味着fork之后产生的额外内存开销，并不一定小。如果快照期间有大量key被修改，Redis就需要复制很多内存页给主进程。极端情况下，Extra内存开销能达到原数据集的好几倍。所以监控Redis内存时，除了正常的used_memory，还要关注used_memory_rss（实际占用的物理内存）。我见过一个实例，平时内存3GB，bgsave期间RSS直接飙到8GB，差点触发OOM。这种场景下，控制单个实例的内存上限、把fork阻塞和内存翻倍风险控制住，比盲目堆大内存更重要。

2.3 RDB文件恢复流程

RDB恢复流程非常简单：Redis启动时，如果配置了dbfilename和dir，并且能找到对应的rdb文件，就会自动加载，加载期间对外服务是阻塞的，直到加载完成。恢复速度取决于文件大小，通常远快于AOF的重放。

手动恢复也容易：停掉Redis，把备份的rdb文件拷贝到dir指定的目录，启动后数据就回来了。这个过程我踩过一次坑——拷贝文件之前没有检查目录权限。Redis进程如果以非root用户启动，通常不能写/var/lib/redis这类系统目录，启动日志会报failed to open the file这类错误，明明文件已经放好了，就是加载不了。后来我习惯用chown确保redis用户有权限，再启动服务。

恢复过程中如果有损坏的rdb文件，Redis启动会直接失败，此时可以用redis-check-rdb工具检查。这个工具也是Redis安装包自带的，用法很简单：redis-check-rdb /path/to/dump.rdb，它可以分析文件是否能被正常解析，以及估算恢复的key数量。我在文件不完整时用它验证过，工具会提示哪些部分损坏。如果文件是从服务器直接拷贝下来的，建议先跑一遍这个检查再入库。

2.4 RDB优劣势梳理

RDB最大的优势是紧凑和快速。二进制文件体积小，传输和备份都很方便；加载时直接内存数据映射，恢复速度远胜AOF。对于需要定期备份、全量迁移的场景，RDB基本是最佳选择。另一个细节是，主从复制的第一次全量同步也是基于RDB快照，这个特性也让RDB成为Redis架构中不可或缺的一部分。

RDB的劣势也很明显：数据持久化粒度不够细，两次快照之间的数据一旦丢失，往往会影响一段时间窗口。例如设定每5分钟一次快照，如果第4分59秒宕机，将近五分钟的数据全部丢失。很多业务能接受这个丢失窗口，但有的业务不能，这就是需要AOF的原因。此外，在大数据量下，fork子进程和写时复制会带来内存和CPU开销，如果快照触发过频，对性能和延迟的影响不容忽视。

3. 再看日志型AOF是怎么记的账

AOF全称Append Only File，逻辑比RDB更直白：Redis每执行一条写命令（包括写入、更新、删除），就把它追加到AOF文件末尾。Redis重启时，把AOF文件里的命令从头到尾重放一遍，数据就恢复了。可以理解为RDB是定期备份整份数据的“全量数据表”，AOF是每次操作都记录一条明细的“流水账日志”。两者组合起来，才是完整的数据保障方案。

3.1 三种写回策略：always、everysec、no

AOF能不能做到“尽量不丢数据”，关键看appendfsync参数的取值。这里先解释一个背景知识：Redis本身写AOF日志用的是系统缓冲区的write调用，数据先进入操作系统的页缓存，内核在合适的时机真正刷到磁盘。如果Redis只是write了日志但内核还没来得及同步到磁盘，此刻机器断电，日志照样丢。所以需要appendfsync来控制刷盘时机。

appendfsync always表示每个命令执行完都立刻调用fsync把日志刷盘。这样做最安全，最多只丢一条正在写入的命令。但代价也明显：每次写操作都要等磁盘完成一次刷盘，性能损失极其严重。我用固态硬盘在Redis Benchmark下测过，always策略下吞吐量大概只有每秒几百到几千次操作量级，比everysec差一个数量级以上，仅适合对数据完整性要求极高、写吞吐极低的场景。

appendfsync everysec是默认值，意思是很每秒调用一次fsync把缓冲区数据刷盘。如果系统宕机，最多丢最近一秒的数据。这是性能和持久性之间比较折中的选择，绝大多数生产环境都用它。还有一点需要注意：每秒刷盘是异步的，Redis主进程不会等fsync完成才处理新命令，所以对吞吐影响很小。

appendfsync no表示不主动控制刷盘时机，完全交给操作系统决定何时落盘。这种方式性能最好，但数据丢失窗口完全不可控，可能在几秒甚至几十秒的时间范围内随机丢失。我在本地压测时，这个策略虽然吞吐高，但是整个系统的数据安全性太飘忽，生产环境几乎不会选它。

提示：三种策略本质是“性能”和“安全”的取舍，没有绝对的对错。但我的实践建议是：默认everysec足够满足大多数业务；真正对数据完整性有强需求的，优先考虑加一层MYSQL之类的数据库兜底，而不是单一依赖always，因为always的写放大问题会在高并发下把Redis拖垮。

3.2 AOF重写机制：为什么日志不会无限膨胀

如果只增不改，AOF文件会一直膨胀下去。比如一个key反复set了10000次，AOF里就存了10000条写入日志，恢复时要把这10000条全部重放，但最终这个key的有效值其实只有最后一条。文件越来越大，磁盘占用高，恢复速度也越来越慢。所以Redis需要定期对AOF进行重写（rewrite），把文件里冗余的历史记录压缩成“当前数据状态的最小命令集”。

AOF重写不是简单地把现有AOF文件“变小”，而是基于当前内存中的数据快照，重新生成一份新的AOF文件。例如内存里有100个key，重写时直接把每个key的当前值以写入命令的形式记录下来，可以生成一份体积小很多的新日志。这个过程同样由fork出的子进程完成，主进程继续处理新写入。子进程生成新的AOF文件期间，主进程收到的写命令会被缓存在AOF重写缓冲区里，在子进程完成后发送给子进程，让新文件包含这部分增量数据。最终原子性地用新AOF文件替换旧文件，整个过程不影响对外服务。

auto-aof-rewrite-percentage和auto-aof-rewrite-min-size控制自动重写的触发条件。默认配置：

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

意思是AOF文件超过64MB后，并且新文件体积比上次重写时的文件体积增长了100%以上（也就是翻倍），触发重写。64MB这个最小阈值的用意，是防止数据量很小时反复重写造成无意义的资源浪费。可如果你在程序里把大量只更新不累积的key频繁写入，AOF文件很快就可能翻倍，重写也会频繁发生，这需要结合业务常量进行调优。

3.3 AOF恢复与文件修复

AOF恢复流程是：Redis启动时如果发现appendonly yes，会优先使用AOF文件来恢复，而不是RDB。Redis把AOF里的每一条命令逐条执行，最终构建出完整的数据集。这个过程比RDB加载慢，但持久化粒度更细，很多业务宁可接受恢复慢一点也不希望丢几分钟数据。

如果AOF文件因为磁盘故障、非法写入等原因损坏了，Redis启动会报错拒绝使用该文件。此时需要用redis-check-aof工具修复，用法：redis-check-aof --fix /path/to/appendonly.aof。这个工具会把有问题的命令截断或者移除，尽量把能恢复的数据救回来。修复会让日志不完美，但总比整个实例起不来强。我经历过一次线上AOF文件因磁盘IO异常产生坏块，当时直接用了fix恢复，最终只丢了最后一小段数据。

补充一个重要经验：AOF修复之前，一定要先给文件留一份备份。不然修复工具可能会改变文件内容，如果修复结果不符合预期，原始文件已经被动过，那就真的没办法了。我的习惯是先cp一份到其他目录再执行修复。

3.4 AOF配置实践建议

推荐生产环境的基本AOF配置：

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

其中no-appendfsync-on-rewrite这个参数值得单独讲。默认值是no，也就是AOF重写期间仍然正常执行appendfsync刷盘，数据安全性和平时一致。如果你把它设成yes，重写期间会暂时关闭fsync，性能更好，但一旦这期间宕机，重写缓冲区甚至普通日志都可能在几十秒时间内丢失。除非你对性能极其敏感且能接受这部分丢失，否则不建议改成yes。

4. RDB与AOF的全面对比与组合使用

聊到这里，RDB和AOF各自优劣已经浮现出来了。RDB恢复快、文件紧凑，但是丢失窗口大；AOF丢失窗口小、数据完整性好，但是文件大、恢复慢。把它们放在一张表格里直接对照，会让选型更清晰。

4.1 混合持久化：现代Redis的默认选项

Redis 4.0之后提供了混合持久化模式，配置文件里对应参数是aof-use-rdb-preamble。它的思路很巧妙：AOF文件的重写结果，不再是一堆纯命令，而是先写入一段RDB二进制快照作为文件头，再在快照后面追加重写期间产生的增量写命令。这样启动恢复时，先快速加载RDB格式的快照数据，然后只重放快照之后那一点点增量命令，恢复速度和AOF的数据完整性兼得。

我印象特别深的是Redis 7.0中，AOF文件重写后的结构分成了多个文件，但混合持久化的核心思路没有变。如果你用的是Redis 4.0以上版本，建议直接开启aof-use-rdb-preamble yes。生产实测里，开启混合持久化后，启动恢复一个大实例的时间从原本纯AOF的几十秒，能缩短到几秒，效果非常明显。

4.2 生产环境选型：不同场景怎么组合

选型这件事，必须从业务角度倒推。如果你的Redis只做缓存，比如商品详情页缓存、验证码缓存，数据源在数据库里，丢了可以从上游重建，那RDB足够，甚至不开启持久化都可以（此时你更关心的是宕机后快速恢复缓存）。这种情况下我一般用RDB，快照频率也不用太高，比如15分钟一次。

如果Redis承担了会话信息、用户登录态、订单短流程状态这类对完整性要求比较高的数据，纯RDB丢失窗口太大，建议开启AOF，同时配置everysec刷盘。这也是我最常推荐的“AOF + everysec”组合，在性能和安全性之间平衡得比较好。理论上最坏丢一秒数据，绝大多数业务都能接受，而性能影响几乎可以忽略。

如果是支付、库存、账务这类非常敏感的数据，只靠Redis持久化是不足以作为唯一数据源的。我建议Redis只做热数据加速，真正的强一致数据必须落在数据库或消息队列里，甚至需要对Redis落盘做更高级的灾备方案。毕竟任何持久化机制都不能保证100%不丢数据，AOF always策略也只能说尽量少丢。

对于有主从副本的环境，还有一个小技巧：只在从节点上开启AOF，主节点只开RDB或不开持久化。这样主节点写入性能完全不受落盘影响，从节点接收全量数据后负责持久化。如果主节点挂了，从节点升主直接顶上，数据不丢的保证落到了从节点的AOF上。这个方法在大规模集群里能显著减轻主节点压力，但前提是你的从节点容量足够撑住AOF带来的磁盘和重启恢复开销。

4.3 磁盘与恢复时间估算：别等出事了才算

刚刚提到的各种方案都有代价，最容易被忽略的就是磁盘空间和恢复时间。这里给出一个简单的估算思路。对于RDB，文件大小基本接近内存数据占用量，如果内存里是3GB数据，dump.rdb一般在2~3GB之间。对于AOF，在良好重写机制下文件大小也接近内存数据量，可如果重写频率跟不上写入频率，文件会膨胀好几倍甚至几十倍。我曾经见过一个实例，内存才2GB，AOF竟然膨胀到30GB，就是因为写入量大且重写阈值设置不合理。

恢复时间很难精确预估，但可以做一个大致的经验判断：RDB加载1GB文件大概需要1~3秒，具体取决于CPU性能和key数量；AOF重放1GB日志可能需要10秒以上，因为每一条命令都要走一次命令执行链路。所以单实例内存比较大的场景（比如10GB以上），我更推荐用RDB做冷备、用AOF做热备，同时搭配混合持久化。你必须在业务可接受的恢复时间范围内做取舍，宁可提前用演练数据压一遍，也不要等到故障时才发现恢复时间远超预期。

4.4 持久化文件的备份与监控

持久化机制本身只是保证进程重启后的数据恢复，硬盘故障、机房故障、误删文件依然可能让持久化文件作废。所以备份后的备份很重要，也就是“异地容灾”。我的标准做法是：每天定时把rdb和aof文件复制到另一台机器或云存储，保留最近N天版本。备份前用redis-cli config get dir确认文件路径，避免复制错文件。

监控方面，重点看两块。一是bgsave的执行情况，通过info persistence可以看到rdb_last_bgsave_status，如果显示err就要查日志；还有rdb_last_cow_size，这个值能反映写时复制的内存开销。二是AOF重写和执行情况，检查aof_last_rewrite_time_sec是否异常长，aof_current_size和aof_base_size比值是否持续增长。这些指标能够提前暴露持久化潜在问题，等出事故再看日志往往就晚了。

5. 实际运维中常见的持久化问题与排查技巧

持久化功能听着简单，但在真实生产环境里，一旦出了问题排查起来非常挠头。这里我把这些年遇到的高频问题按“症状—原因—解法”整理出来，方便你直接对照排查。

5.1 数据丢了一大截，恢复后只剩旧数据

症状：重启Redis后，发现数据回到了几天前甚至几周前的状态，中间写入的数据全部消失。

常见原因一：只配置了RDB且快照间隔太长。例如save 900 1意味着900秒内如果有1次写操作才做一次快照，低写入业务可能要很久才触发一次，一旦宕机数据自然回到上次快照时间点。解法是缩短快照间隔或开启AOF，例如配置save 60 1加上appendonly yes。

常见原因二：shutdown时没有正常触发快照。有些运维流程直接kill -9杀进程，SQL客户端或管理软件把Redis强杀，导致最后一次快照根本没机会生成，重启加载到的是上一个旧快照。解法是用shutdown nosave或shutdown save优雅关闭，不要用kill强杀。

常见原因三：多个实例共用一个rdb文件路径。例如两个Redis实例没有设置各自的dir和dbfilename，把同一个dump.rdb互相覆盖，最终恢复出了另一个实例的数据。这个坑很隐蔽，排查时一定要看每个实例的config get dir。

5.2 Redis启动直接失败，加载不了持久化文件

症状：进程启动后很快就退出，日志里出现Bad file format、Can't open AOF file或Error in fsync之类的错误。

排查步骤：第一，用redis-check-rdb或redis-check-aof --fix检查文件是否损坏。如果文件损坏，先备份再修复。第二，检查磁盘空间，df -h看一下对应目录是否满了，log里出现No space left on device的，优先清盘或扩容。第三，检查文件权限，ls -l确认文件对运行Redis的用户可读可写。我自己就栽过这个跟头，把rdb文件放到新机器上，忘了改属主，Redis启动时直接拒绝加载。

5.3 bgsave触发后Redis响应变慢，延迟飙升

症状：业务反馈Redis延迟偶尔抖动到几百毫秒甚至秒级，查看日志发现和bgsave触发时间高度吻合。

原因通常是fork耗时太长。fork一个超大进程需要遍历内存页表，如果实例内存几十GB，fork可能耗时接近一秒。更麻烦的是，fork期间主进程会阻塞，阻塞时间越长对业务影响越大。解法有几个方向：控制单实例内存，建议通用场景不超过20GB，需要更大数据量时就拆分集群；调整stop-writes-on-bgsave-error yes这个参数，虽然默认是yes表示bgsave失败后拒绝写入，但如果磁盘出问题可能会导致写入彻底不可用，视业务情况决定是否改为no；优化快照触发频率，避免高频写业务下自动快照过于频繁。

写时复制造成的内存暴涨也可能拖慢主进程，因为分配内存页和复制页会有额外的CPU和内存压力。我遇到过一台内存富裕的机器，bgsave期间主进程GC变慢，命令延迟明显上升。这类问题没有银弹，只能靠监控提前暴露，然后调整快照策略或者改用混合持久化，把bgsave次数降下来。

5.4 AOF重写频繁导致磁盘IO压力大

症状：磁盘IO持续很高，掉队检查发现AOF文件不断在重写，甚至出现多个重写子进程同时跑。

原因通常是把auto-aof-rewrite-min-size设得太小，或者业务写入量大，导致每次重写后文件很快又翻倍。比如64MB最小阈值，对高并发写入来说几分钟就触发一次翻倍重写，子进程频繁fork，磁盘IO自然压满。解法：适当调大auto-aof-rewrite-min-size，比如256MB或512MB；调大auto-aof-rewrite-percentage，比如从100改成200；或者在业务低峰期手动执行bgrewriteaof，主动控制重写窗口。

另一个容易忽视的点是no-appendfsync-on-rewrite参数。如果设成yes，重写期间刷盘暂停，重写完成后立刻恢复，很短时间窗口内磁盘IO会有一个陡增峰值。如果磁盘本来压力就大，这个峰值可能导致监控报警。我一般建议在SSD上保持默认的no，保持刷盘稳定性；在机械硬盘上可以设成yes，但必须接受数据安全性略降。

5.5 主从复制和持久化之间的纠缠

场景：主从架构下，从节点执行全量同步会触发主节点bgsave，而bgsave期间主节点又因为写时复制内存暴涨，导致主节点延迟。这在内存大、写入频繁的实例上更明显。

另一个典型的坑是：从节点挂在的时候，如果你的主节点repl-backlog-ttl和过期策略设置不合理，从节点在短时间尝试重连，如果主节点复制积压缓冲区里的数据已经因为过期被清理，只能走全量同步。全量同步又触发主节点bgsave，加上AOF和日志的IO压力，主节点CPU和磁盘一下子就顶上去了。我建议在全量同步高峰期提前观察监控面板，必要时手工调整全量同步任务到业务低峰，或者在从节点拉起临时快照文件来同步。

还有一点要留意：开启混合持久化后，从节点在进行全量同步时拿到的数据文件可能带RDB头部，如果这一份数据同时被同步到其他从节点，网络带宽消耗会更大。不过相对整体性能来说，混合持久化仍然利大于弊，这个影响通常可以接受。

5.6 一条我深信不疑的兜底原则

不管RDB还是AOF，持久化文件都不是业务数据的最终保险。持久化文件也可能因为误删、磁盘坏道、代码bug而被破坏。我见过有人在阿里云OSS上备份了rdb文件，但备份系统只保留了最近两天，结果线上故障发生后两天才暴露，点开发现备份文件也是坏的——就因为备份机磁盘也满了，写入中断。从那之后我给自己定了一条硬规矩：持久化文件要备份，备份的备份还要做恢复演练；定期从一个备份文件里启一个临时Redis实例，检查数据能不能正常恢复。只有实际恢复过，你才敢说这个备份能用。

5.7 排查时需要掌握的几个命令

排查持久化问题时，下面的命令是高频率会用的，整理出来给你参考：

# 查看持久化相关配置 redis-cli CONFIG GET save redis-cli CONFIG GET appendonly redis-cli CONFIG GET appendfsync redis-cli CONFIG GET dir # 查看持久化运行状态 redis-cli INFO persistence # 手动触发 redis-cli BGSAVE redis-cli BGREWRITEAOF # 检查RDB/AOF文件 redis-check-rdb /data/redis/dump.rdb redis-check-aof --fix /data/redis/appendonly.aof # 查看当前时间点 redis-cli LASTSAVE

INFO persistence输出中包含了许多关键指标，例如rdb_last_bgsave_status、rdb_last_cow_size、aof_last_rewrite_time_sec、aof_current_size与aof_base_size。这些字段我都建议加入监控平台的采集项，一旦异常直接告警。

6. 一个常见方案的配置示例

把前面讲的整合起来，一套比较接近生产环境的Redis持久化配置大概是这样的：

# RDB配置 save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir /data/redis # AOF配置 appendonly yes appendfilename "appendonly.aof" appendfsync everysec no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 混合持久化 aof-use-rdb-preamble yes

这套配置下，Redis兼具RDB的快速全量备份能力和AOF的细粒度数据恢复能力。大多数业务场景，包括那些对数据相对敏感的会话、库存类应用，在合理的监控和备份配合下，基本能顺畅运行。

如果是纯缓存场景且不想有额外IO开销，也可以把RDB快照间隔拉长，甚至关闭AOF。比如这样：

save 3600 1 appendonly no

此时Redis更像一个“重启即失忆但恢复快”的缓存工具，数据完整性由上游数据库保证。这其实也是一种合理的设计，关键是团队要达成共识，不要默认Redis一定会存住所有数据。

7. 我最后想嘱咐的几句话

从事Redis运维这些年，我越来越觉得持久化配置虽然只占配置文件几行字，但每次线上故障复盘，十次里至少有三四次都跟它有关。很多人对Redis的印象就是“快”，忽视了快背后的脆弱；也有些人觉得持久化开了就万事大吉，结果没有做备份和恢复演练，真出事时同样抓瞎。RDB和AOF的选择不是一道非黑即白的判断题，而是一条以数据安全性、恢复时间、磁盘成本、性能开销为轴线的权衡曲线。你只需要把每条轴上的需求搞清楚，配置自然就出来了。另外一个我反复提醒自己的点是：任何时候都要先在测试环境做一次完整的停机恢复演练，只有真正亲手把rdb文件或aof文件加载起来，你才能摸清这套方案的底牌。希望这篇文章能帮你少走一些我曾经绕过的弯路。