1. 为什么持久化是Redis的命门很多人第一次接触Redis脑子里装的都是“快”。内存操作、单线程模型、epoll多路复用这些标签叠加在一起让Redis成了缓存场景的默认答案。但快有一个代价——数据在内存里进程一挂全没。你可能会说缓存丢了就丢了回源查数据库就行。这话对了一半。当Redis只做缓存时持久化确实可以关掉性能还能再榨一截。可一旦你把Redis用在会话存储、分布式锁、排行榜、消息队列、购物车这些场景数据丢了就是事故。我见过一个真实案例某团队用Redis存用户登录态没开持久化机房网络抖动导致主从切换新主节点内存是空的所有用户瞬间被踢下线客服电话被打爆。事后复盘他们以为“主从复制就够了”但主从复制是异步的主节点挂掉的瞬间还没同步到从节点的数据就永久消失了。持久化解决的是“重启后数据还在”的问题复制解决的是“节点挂了服务还能用”的问题两者不是一回事。Redis提供了两种持久化方式RDB和AOF。RDB是快照把某一时刻的内存数据全量写进磁盘AOF是日志把每一条写命令追加到文件里。两者各有各的脾气也各有各的坑。这篇文章我会从底层实现的角度把RDB和AOF拆开揉碎讲清楚包括fork和写时复制、AOF缓冲区刷新策略、重写机制、混合持久化以及生产环境怎么选、怎么配、怎么排查问题。不管你是刚接触Redis的新手还是已经用过几年但没深究过底层的老手应该都能从里面找到一些之前没注意到的细节。提示本文基于Redis 7.x版本的实现来讲解部分参数在6.x及更早版本中行为略有差异我会在涉及的地方标注出来。2. RDB持久化快照背后的fork与写时复制2.1 RDB到底做了什么RDB的全称是Redis Database本质上就是一个经过压缩的二进制文件里面存的是某个时间点上Redis内存中所有键值对的数据。你可以把它理解成给内存拍了一张照片恢复的时候直接把照片里的数据重新加载回内存。触发RDB的方式有三种手动执行SAVE命令、手动执行BGSAVE命令、以及通过配置自动触发。SAVE命令会阻塞Redis主线程直到快照写完为止生产环境基本不会用。BGSAVE会fork出一个子进程来写快照主线程继续处理客户端请求这是最常用的方式。自动触发则是通过save配置项比如save 900 1表示900秒内至少有1个键被修改就触发一次BGSAVE。RDB文件默认叫dump.rdb可以通过dbfilename配置项修改。文件格式分为几个部分头部是REDIS魔数和版本号接着是辅助字段比如Redis版本、创建时间、内存占用等然后是数据库编号和键值对数据最后是EOF标记和CRC64校验和。校验和用来检测文件是否损坏如果rdbchecksum开启默认开启加载时会验证CRC64不匹配就报错拒绝加载。2.2 fork和写时复制RDB不阻塞主线程的秘密BGSAVE之所以能不阻塞主线程核心在于fork和写时复制Copy-On-Write简称COW。fork是操作系统提供的系统调用它会创建一个子进程这个子进程拥有和父进程几乎完全一样的内存空间。在Linux上fork采用COW机制也就是说fork的瞬间并不会真的复制一份物理内存而是让父子进程共享同一份内存页把这些页标记为只读。当父进程或子进程试图修改某个页时操作系统才会为该页复制一份副本修改方操作副本另一方继续用原来的页。Redis利用这个机制让子进程去遍历内存数据写RDB文件父进程继续处理写命令。父进程修改数据时触发COW子进程看到的是fork那一刻的内存快照数据一致性由此得到保证。但COW不是没有代价的。如果fork之后父进程有大量写操作就会频繁触发页复制内存占用会迅速膨胀。极端情况下内存可能翻倍。我实测过一个场景一个实例用了8GB内存fork之后持续高写入子进程还没写完内存已经涨到14GB触发了OOM KillerRedis进程被系统杀掉。所以生产环境做RDB时一定要确保机器有足够的内存余量通常建议预留50%以上的空闲内存。还有一个细节fork本身是阻塞的。虽然COW让内存复制变得廉价但fork需要复制页表页表的大小和内存量成正比。一个用了20GB内存的Redis实例页表可能有几十MB甚至上百MBfork耗时可能达到几百毫秒甚至秒级。这段时间主线程是卡住的客户端请求会超时。所以单个Redis实例的内存不宜过大业界一般建议不超过10GB到16GB除了fork耗时还有主从全量同步时的RDB传输耗时、故障恢复时的加载耗时等考量。2.3 RDB的触发时机与配置策略自动触发的配置项是save seconds changes可以配置多条。比如save 900 1 save 300 10 save 60 10000意思是900秒内至少1个键被修改或300秒内至少10个键被修改或60秒内至少10000个键被修改就触发BGSAVE。这三个条件满足任意一个就会触发。注意这里的“键被修改”指的是写命令执行后导致数据发生变化的次数不是客户端请求数。除了save配置还有几个场景会触发RDB主从全量同步时主节点会生成RDB发给从节点执行SHUTDOWN命令时如果没有开启AOF会触发一次SAVE执行DEBUG RELOAD时也会生成RDB。关闭自动RDB有两种方式一是把save配置写成空字符串save 二是注释掉所有save行。但即使关闭了自动RDB手动BGSAVE和主从同步时的RDB仍然会执行。注意有些团队为了性能把save全关了但忘了主从同步也会触发RDB。如果从节点做全量同步时主节点内存很大fork阻塞加上COW内存膨胀同样可能出问题。2.4 RDB的优缺点与适用场景RDB最大的优点是文件紧凑、恢复速度快。同样数据量RDB文件通常比AOF文件小得多加载时直接解析二进制、重建内存比逐条重放AOF命令快很多。一个10GB的RDB文件加载可能只需要几十秒同样数据的AOF可能要几分钟甚至更久。缺点也很明显快照是周期性的两次快照之间的数据如果发生故障就会丢失。比如save 900 1最坏情况下可能丢15分钟的数据。对于不能容忍数据丢失的场景RDB单独使用是不够的。另外fork时的阻塞和COW的内存膨胀是RDB的固有代价无法完全消除只能通过控制实例大小、错峰执行、预留内存来缓解。RDB适合的场景数据可以容忍分钟级丢失、需要快速恢复、做冷备和灾难恢复、主从全量同步。很多团队用RDB做每日备份用AOF做实时持久化两者结合使用。3. AOF持久化命令日志的写入与重写3.1 AOF的工作流程AOF的全称是Append Only File它记录的是所有写命令以Redis协议格式追加到文件末尾。恢复时Redis会创建一个伪客户端逐条执行AOF文件里的命令把数据重建出来。AOF的流程分为三步命令追加、文件写入、文件同步。命令追加当一条写命令执行完成后Redis会把它追加到aof_buf缓冲区里。注意命令是在执行后才追加的不是执行前。这意味着如果命令执行到一半Redis挂了AOF里不会有这条命令数据一致性由Redis的单线程模型保证——命令要么完整执行要么完全不执行。文件写入Redis的主线程在每次事件循环结束前会调用flushAppendOnlyFile函数把aof_buf里的内容写入到AOF文件的内核缓冲区。注意这里是写入内核缓冲区不是直接落盘。文件同步根据appendfsync配置项决定何时把内核缓冲区的数据真正刷到磁盘。这个配置决定了AOF的可靠性和性能。3.2 appendfsync的三种策略appendfsync有三个可选值always、everysec、no。always每条写命令都调用fsync刷盘。可靠性最高最多丢一条命令。但性能最差因为fsync是阻塞的系统调用每次都要等磁盘确认写入完成。机械硬盘上QPS可能降到几百SSD上也就几千。生产环境基本不用。everysec每秒调用一次fsync。这是默认值也是绝大多数场景的推荐值。最多丢1秒的数据。性能接近不刷盘因为fsync是在后台线程里执行的不阻塞主线程。但要注意如果上一秒的fsync还没完成主线程会阻塞等待直到fsync完成。这是为了防止缓冲区无限增长。no不主动调用fsync由操作系统决定何时刷盘。通常Linux会每隔30秒刷一次。可靠性最差但性能最好。适合对数据丢失不敏感、追求极致性能的场景。我个人的经验是99%的场景用everysec就够了。always只在金融级、不能丢任何数据的场景用而且要用SSD。no基本不用因为省不了多少性能但风险大很多。3.3 AOF重写为什么需要以及怎么实现AOF是追加写入的随着时间推移文件会越来越大。比如你反复对一个计数器执行INCRAOF里会有成千上万条INCR命令但实际数据只是一个数字。AOF重写就是来解决这个问题的它根据当前内存数据生成一份最小的命令集让恢复后的数据状态和当前一致。AOF重写不是读取旧AOF文件来压缩而是直接遍历内存数据反向生成命令。比如一个列表有100个元素旧AOF里可能有1000条RPUSH重写后只需要一条RPUSH带上100个元素。一个键如果已经过期重写时直接跳过。重写由BGREWRITEAOF命令触发或者通过auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置自动触发。前者表示AOF文件比上次重写后增长了多少百分比时触发默认100%后者表示AOF文件至少达到多大才触发默认64MB。两个条件要同时满足。重写的过程和BGSAVE类似fork一个子进程子进程遍历内存生成新AOF文件父进程继续处理写命令。但这里有一个问题子进程重写期间父进程的新写命令怎么办如果不管新AOF文件就会缺数据。Redis的解决方案是父进程把重写期间的新写命令同时追加到aof_rewrite_buf缓冲区里。子进程重写完成后父进程把aof_rewrite_buf里的内容追加到新AOF文件末尾然后用新文件替换旧文件。这样新AOF文件就包含了重写开始时的数据快照加上重写期间的所有写命令数据完整。重写期间同样有fork阻塞和COW内存膨胀的问题和RDB一样。而且重写期间如果写入量很大aof_rewrite_buf会占用额外内存如果超过client-output-buffer-limit里的限制可能会出问题。不过这个限制主要针对从节点主节点的重写缓冲区一般不会触发限制。3.4 AOF的优缺点与适用场景AOF的优点是可靠性高everysec最多丢1秒数据always几乎不丢。而且AOF文件是可读的文本格式虽然是Redis协议出问题时可以手动检查和修复。比如某条命令写了一半可以用redis-check-aof --fix修复。缺点是文件大、恢复慢。同样数据量AOF文件通常是RDB的几倍甚至十几倍。恢复时逐条重放命令速度比RDB加载慢很多。另外AOF重写虽然能压缩文件但重写本身也有开销。AOF适合的场景对数据丢失敏感、不能容忍分钟级丢失、需要审计写操作、做实时持久化。很多团队用AOF做主持久化用RDB做冷备和快速恢复。4. 混合持久化RDB和AOF的取长补短4.1 混合持久化的原理RDB恢复快但可能丢数据AOF丢数据少但恢复慢。有没有办法兼得Redis 4.0引入了混合持久化Redis 5.0默认开启。它的思路是AOF重写时不再生成纯命令格式的AOF文件而是先生成一份RDB格式的快照追加到新AOF文件的开头然后把重写期间的新写命令以AOF格式追加到后面。这样新AOF文件就是“RDB头 AOF尾”的结构。恢复时Redis先加载RDB部分快速重建大部分数据然后重放AOF部分的命令补上重写期间的增量。这样既有了RDB的恢复速度又有了AOF的低丢失率。混合持久化通过aof-use-rdb-preamble配置项控制默认yes。关闭后AOF重写就回到纯命令格式。4.2 混合持久化的配置与注意事项开启混合持久化后AOF文件不再是纯文本开头是二进制RDB后面是文本命令。用文本编辑器打开会看到乱码这是正常的。redis-check-aof工具仍然可以检查和修复AOF部分但RDB部分需要redis-check-rdb来检查。有一个坑要注意混合持久化下AOF文件的前半部分是RDB格式如果RDB部分损坏整个AOF文件可能无法加载。而纯AOF格式下即使中间某条命令损坏可以用--fix跳过继续加载后面的命令。所以混合持久化在容错性上不如纯AOF。不过RDB部分有CRC64校验损坏的概率很低。另一个坑是版本兼容性。混合持久化的AOF文件不能被Redis 4.0之前的版本加载。如果你需要降级Redis版本要先把aof-use-rdb-preamble设为no执行一次BGREWRITEAOF把AOF文件转成纯命令格式再降级。4.3 生产环境怎么选我的建议是绝大多数场景直接用混合持久化也就是aof-use-rdb-preamble yes加上appendfsync everysec。这样最多丢1秒数据恢复速度也快。如果对数据丢失零容忍把appendfsync改成always但要有性能下降的心理准备。如果只用RDB适合纯缓存场景或者能容忍分钟级丢失的场景。如果只用AOF适合需要审计写操作的场景但恢复慢的问题要接受。还有一点不管用哪种持久化都要做备份。持久化不等于备份。持久化是防止进程重启丢数据备份是防止磁盘损坏、误删除、机房故障。我见过有人开了AOF就以为万事大吉结果磁盘坏了AOF和RDB在同一个盘上一起没了。备份要异地、要定期、要验证可恢复性。5. 持久化实操配置、监控与故障排查5.1 生产环境推荐配置以下是一份我常用的生产环境持久化配置基于Redis 7.x# RDB配置 save 900 1 save 300 10 save 60 10000 dbfilename dump.rdb dir /data/redis rdbcompression yes rdbchecksum yes stop-writes-on-bgsave-error yes # 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-load-truncated yes aof-use-rdb-preamble yes几个关键项解释一下。stop-writes-on-bgsave-error yes表示如果BGSAVE出错Redis停止接受写命令。这是为了防止用户不知道持久化已经失败继续写入导致数据丢失。但有些场景下比如磁盘满了但服务不能停可以设为no同时做好监控。no-appendfsync-on-rewrite no表示重写期间仍然执行fsync。如果设为yes重写期间不刷盘性能更好但可能丢更多数据。默认no建议保持。aof-load-truncated yes表示AOF文件末尾不完整时加载时忽略末尾的截断部分继续启动。如果设为no加载会失败需要手动修复。生产环境建议yes避免因为一点截断导致服务起不来。5.2 监控指标与告警项持久化相关的监控指标主要有几个rdb_last_bgsave_status最近一次BGSAVE的状态ok或err。如果是err要立即排查。rdb_last_bgsave_time_sec最近一次BGSAVE耗时单位秒。如果持续增长说明数据量在涨或者磁盘变慢。rdb_changes_since_last_save距离上次BGSAVE以来有多少次写操作。如果这个值很大但一直没触发BGSAVE检查save配置。aof_last_bgrewrite_status最近一次AOF重写状态。aof_last_write_status最近一次AOF写入状态。aof_current_size和aof_base_size当前AOF文件大小和上次重写后的大小。两者比值超过auto-aof-rewrite-percentage时会触发重写。latest_fork_usec最近一次fork耗时单位微秒。如果超过100毫秒要关注。这些指标可以通过INFO persistence命令获取。建议接入监控系统对rdb_last_bgsave_status和aof_last_write_status做告警一旦变成err立即通知。5.3 常见问题排查问题一BGSAVE失败报“Cant save in background: fork: Cannot allocate memory”这是fork失败通常是因为系统内存不足或者vm.overcommit_memory设置不对。Linux默认vm.overcommit_memory0表示内核会启发式地判断是否有足够内存。Redis fork时需要申请和父进程同样大小的内存虽然COW不会真的分配但内核在fork时可能会拒绝。解决办法是把vm.overcommit_memory设为1表示总是允许超额分配。命令是sysctl vm.overcommit_memory1写入/etc/sysctl.conf永久生效。问题二AOF文件越来越大重写不触发检查auto-aof-rewrite-percentage和auto-aof-rewrite-min-size。如果AOF文件没到64MB即使增长比例很大也不会触发。可以手动执行BGREWRITEAOF。另外如果aof_current_size和aof_base_size的比值没超过配置的百分比也不会触发。可以调低auto-aof-rewrite-percentage比如改成50。问题三Redis启动时加载AOF很慢AOF加载慢是正常的因为要逐条重放命令。如果慢到无法接受考虑开启混合持久化让大部分数据以RDB格式加载。另外检查AOF文件是否过大如果超过几个GB考虑做一次重写。问题四主从同步时从节点加载RDB失败检查主从节点的Redis版本是否一致RDB格式在不同版本间可能有差异。另外检查dbfilename和dir配置从节点会把主节点发来的RDB先存到磁盘再加载如果磁盘空间不足会失败。问题五appendfsync always下性能急剧下降这是预期行为。always每条命令都fsync磁盘IO成为瓶颈。如果必须用always换SSD并且考虑用多实例分摊写入。或者改用everysec接受最多1秒的数据丢失。5.4 实操心得与避坑技巧第一个心得不要在主节点上做RDB备份。主节点做BGSAVE会fork阻塞主线程COW还会膨胀内存。正确做法是在从节点上做备份从节点fork不影响主节点服务。如果只有主节点考虑加一个从节点专门做备份。第二个心得AOF重写和RDB不要同时进行。虽然Redis会串行化这两个操作但同时触发会导致fork两次内存膨胀更严重。可以通过配置错开触发时机比如RDB的save配置和AOF重写的auto-aof-rewrite-percentage配合调整。第三个心得定期验证备份可恢复性。我见过太多团队备份文件一堆真出事时发现恢复不了。建议每周至少做一次恢复演练把备份文件加载到一个测试实例确认数据完整。第四个心得磁盘空间要留足。RDB和AOF文件可能很大重写时还需要额外空间存新文件。建议磁盘使用率不超过70%。另外dir配置的目录要和Redis进程在同一台机器上不要用网络存储延迟太高。第五个心得aof-load-truncated设为yes但要监控。设为yes能让Redis在AOF末尾截断时正常启动但截断意味着可能丢了数据。启动后要检查日志确认截断了多少评估影响。6. 底层原理延伸从源码角度看持久化6.1 RDB的写入流程RDB的写入在rdb.c里实现。rdbSave函数负责把数据写到文件rdbSaveRio是核心它遍历所有数据库对每个键值对调用rdbSaveObject根据对象类型选择不同的编码方式。比如字符串直接写列表如果元素少且都是整数用特殊编码压缩。BGSAVE的实现在rdbSaveBackground里。它先检查是否已有子进程在跑如果有就返回错误。然后调用fork子进程执行rdbSave父进程记录子进程PID继续处理请求。子进程完成后通过信号通知父进程父进程在serverCron里检查子进程状态更新统计信息。6.2 AOF的写入与重写流程AOF的写入在aof.c里。feedAppendOnlyFile函数把写命令追加到aof_buf。flushAppendOnlyFile在事件循环里被调用根据appendfsync决定是否fsync。AOF重写在rewriteAppendOnlyFileBackground里。它fork子进程子进程调用rewriteAppendOnlyFile生成新AOF文件。父进程把重写期间的新命令追加到aof_rewrite_buf。子进程完成后父进程把aof_rewrite_buf写入新文件然后rename替换旧文件。混合持久化的实现在rewriteAppendOnlyFile里如果aof-use-rdb-preamble开启先调用rdbSaveRio写RDB部分再写AOF部分。6.3 fork和COW的底层细节fork是Linux的系统调用在glibc里封装为fork()。它复制父进程的页表把内存页标记为只读。当任一进程写这些页时触发缺页异常内核分配新页并复制内容。这个过程对用户态透明。Redis在fork前后会做一些优化。比如serverCron里会检查server.child_pid如果有子进程在跑就不触发新的BGSAVE或BGREWRITEAOF。另外serverCron会调用waitpid检查子进程是否完成避免僵尸进程。COW的内存膨胀可以通过INFO memory里的mem_fork相关指标观察。Redis 7.x提供了mem_fork统计可以看fork时复制了多少页。如果这个值很大说明COW开销大要考虑优化。7. 持久化方案选型与容量规划7.1 不同场景的选型建议场景推荐方案理由纯缓存关闭持久化数据可回源持久化浪费性能会话存储混合持久化 everysec最多丢1秒恢复快分布式锁AOF everysec锁数据不能丢RDB可能丢分钟级排行榜RDB 定期备份可容忍短时丢失恢复快消息队列AOF always消息不能丢性能要求相对低购物车混合持久化 everysec平衡可靠性和性能7.2 容量规划RDB文件大小通常是内存数据的1/2到1/3取决于压缩率和数据特征。AOF文件大小通常是内存数据的2到5倍取决于写入模式和重写频率。混合持久化的AOF文件大小介于两者之间。磁盘空间规划至少预留内存数据的3倍空间。比如10GB内存的实例磁盘至少30GB。如果做备份再乘以备份份数。内存规划fork时COW可能膨胀50%到100%所以机器内存至少是Redis内存的1.5倍。比如10GB的Redis实例机器至少16GB内存建议32GB。7.3 性能影响评估RDB的BGSAVE对性能的影响主要在fork瞬间的阻塞和COW的内存膨胀。fork耗时和内存量成正比10GB实例大约100到200毫秒。COW膨胀取决于写入量写入越频繁膨胀越大。AOF的everysec对性能影响很小因为fsync在后台线程执行。但重写时fork同样有阻塞。always对性能影响大QPS可能下降一个数量级。混合持久化的性能和AOFeverysec接近恢复速度接近RDB。8. 常见问题速查表问题可能原因解决方法BGSAVE失败内存不足或overcommit设置设vm.overcommit_memory1增加内存AOF重写不触发文件未达min-size或增长比例不够调低auto-aof-rewrite-percentage启动加载慢AOF文件大或纯AOF格式开启混合持久化做AOF重写fork耗时高实例内存过大拆分实例控制单实例内存COW内存膨胀写入量大错峰执行预留内存AOF文件损坏写入中断或磁盘故障redis-check-aof --fix修复主从同步失败版本不一致或磁盘满统一版本清理磁盘持久化文件丢失磁盘故障或误删除异地备份定期验证这个速查表是我从多次故障处理中总结出来的覆盖了80%以上的持久化问题。遇到问题时先查表能快速定位方向。9. 我个人在实际操作中的体会持久化这块我踩过的坑比成功经验多。最早的时候觉得开了AOF就万事大吉结果磁盘满了AOF写入失败Redis还在接受写命令等发现时已经丢了几小时数据。后来加了stop-writes-on-bgsave-error yes和监控告警才没再出过类似问题。还有一次一个实例用了20GB内存BGSAVE时fork阻塞了将近1秒客户端大量超时。后来把实例拆成两个10GB的fork耗时降到200毫秒以内问题解决。这件事让我深刻理解到Redis实例不是越大越好单实例内存控制在10GB以内是有道理的。混合持久化刚出来时我不敢用怕兼容性问题。后来在测试环境验证了几个月确认稳定后才上生产。现在新部署的实例默认开混合持久化恢复速度确实快很多。一个8GB的实例纯AOF恢复要3分钟混合持久化只要30秒。最后分享一个小技巧如果磁盘IO是瓶颈可以把RDB和AOF文件放到不同的磁盘上减少IO竞争。另外dir配置的目录不要和Redis日志、系统日志放一起避免日志写入影响持久化性能。这些细节看起来不起眼但在高负载场景下能明显改善稳定性。
