1. Redis为什么需要持久化先搞清楚数据丢失到底丢在哪Redis作为内存数据库高性能的核心就是把数据放在内存里。但成也内存、败也内存——一旦进程退出、机器重启或者断电内存中的数据就全部清空。很多人第一次用Redis时都有过这种经历明明set了一堆数据服务一重启啥都没了。那种感觉就像辛辛苦苦写了一晚上文档没保存电脑突然关机。有人会说Redis不是可以用来做缓存吗缓存丢了不就丢了重新查一遍数据库就行了。这句话对纯缓存场景成立但Redis的用途早就超出了缓存范畴。很多人拿它存会话token、存排行榜、存计数器的值、存分布式锁的状态、甚至存订单的临时状态。这些数据一旦丢失要么用户得重新登录要么计数对不上账要么锁失效导致并发问题。所以数据不丢失不是一句口号而是Redis在生产环境落地时必须解决的问题。Redis的解决方案就是持久化目前一共两条路线RDB快照和AOF日志。RDB把某一时刻的全量数据打包落地成二进制文件AOF则把每一条写操作命令追加记录到日志文件。两者各有优劣后来Redis又把它们结合成混合持久化。这篇文章我会把这两条路线的原理、触发机制、参数配置、常见坑全部掰开揉碎讲清楚最后附上我实际运维中的推荐配置和排查经验。不管你是在用Redis做缓存、做消息队列的中间存储还是在做数据结构服务这篇文章都值得看完。尤其是那些把Redis当数据库用的朋友理解持久化的细节会直接影响你设计高可用方案时的决策。2. RDB快照定时存盘简单粗暴的全家福2.1 RDB的触发机制与配置RDB可以理解为拍照。不管Redis里头存了多少数据到了触发条件就把此刻所有数据完整地写进一个dump.rdb文件。这个文件是二进制格式恢复时直接读进来加载到内存速度非常快。往生产环境上一放RDB一般有以下几种触发方式。第一种是save命令触发会阻塞Redis主进程直接同步生成RDB文件。在数据量大的时候会让你明显感觉到卡顿生产环境我基本不用它。第二种是bgsave命令触发Redis会fork一个子进程去生成RDB文件主进程继续对外服务。这是实际生产环境中用的最多的一种触发方式后面我会详细讲fork和写时复制的原理。第三种是自动触发。通过配置项save指定触发条件格式是save [秒数] [写次数]比如默认配置里常见的save 900 1 save 300 10 save 60 10000意思就是900秒内有1次写操作就触发一次bgsave300秒内有10次写操作触发一次60秒内有10000次写操作触发一次。只要满足任何一个条件Redis就会自动执行bgsave。还有一种容易被忽略的触发方式Redis正常关闭时会自动生成一次RDB文件在主从复制场景下从节点执行全量复制时主节点也会触发bgsave来生成快照发送给从节点。RDB文件默认生成在dir配置指定的目录下文件名由dbfilename配置决定默认是dump.rdb。如果你自己改了配置务必确认两者配套否则会出现明明触发了保存文件却不在预期位置的问题。2.2 RDB文件的生成过程fork与写时复制很多教程讲到bgsave就是简单一句后台保存但背后其实涉及操作系统层面的一个关键机制——fork。fork是Unix系统创建子进程的系统调用Redis主进程调用fork后会得到一个和父进程几乎一样的子进程。关键点来了fork刚完成时子进程和父进程共享同一份物理内存并没有把数据完整复制一份。这是通过操作系统的写时复制Copy On WriteCOW实现的。子进程负责把当前的内存数据遍历一遍写入RDB文件。在子进程写文件的过程中如果主进程正好收到新的写请求Redis会修改内存数据这时操作系统会把这部分被修改的内存页复制一份给主进程使用子进程那边看到的还是fork瞬间的数据。明白了这个过程你就会理解两个运维中的常见现象。一个是为什么bgsave期间内存占用会莫名升高。因为如果写操作频繁被修改的内存页需要复制额外的物理内存开销可能达到原来的数倍。所以在内存本来就紧张的机器上bgsave可能触发内存溢出甚至被系统OOM杀掉。这也解释了为什么Redis一般不建议部署在内存使用率长期超过70%的机器上。另一个是为什么fork本身可能很耗时。fork需要拷贝进程的页表等元数据Redis实例里存的数据越多、key数量越多fork耗时越长。在fork期间主进程是阻塞的。如果是一个存储几十GB数据的大实例fork耗时可能达到几十毫秒甚至更久对延迟敏感的业务就是一次可见的抖动。我见过一次线上事故某实例内存将近30GB每小时的bgsave都会导致主进程阻塞100多毫秒直接拖垮了几个核心接口的RT。后来优化方式是把快照频率降低并改用混合持久化情况才缓解。2.3 RDB的优缺点与适用场景RDB的优点很突出。文件紧凑、加载速度快恢复大数据集时比AOF快得多。因为它是二进制格式几乎就是内存数据的镜像加载时直接解析还原不需要像AOF那样一条一条重放命令。RDB文件也方便做跨机房备份拷走一份dump.rdb到另一台机器上启动就能用。缺点同样明显。最大的问题就是丢数据。它做不到实时持久化两次快照之间的数据一旦发生宕机就永久丢失。假设你配置的是save 900 1那最多可能丢15分钟的数据。哪怕你调成save 60 1最多也可能丢60秒。这个窗口对很多业务来说是不可接受的。另外fork子进程的机制决定了它在数据量大时对性能有冲击。虽然bgsave不会阻塞主进程但前面说的fork阻塞和COW带来的内存开销高并发场景下不可忽视。所以RDB比较适合这些场景对数据丢失容忍度较高的缓存场景作为冷备方案定期把RDB文件归档或者配合AOF使用RDB作为快速恢复的底包。单独用RDB扛数据不丢失几乎是不现实的。3. AOF日志记录每一次写操作细水长流3.1 AOF的写回策略与appendfsync参数说完了快照再来看看另一种思路。AOFAppend Only File不记录数据本身而是记录命令。每当有写命令执行成功Redis就把这条命令追加到aof文件末尾。恢复的时候只要把aof文件里的命令从头到尾重放一遍就能把数据还原出来。理论上如果你能做到命令写入内存后立刻同步到磁盘那你最多只丢一条命令基本等于不丢数据。问题在于立刻写磁盘在性能上代价太高。为了让用户在数据安全与性能之间做权衡Redis提供appendfsync参数一共有三个取值。always表示每次写命令执行成功后都调用fsync强制刷盘。这种方式最安全最多丢一条命令但性能损失极大。实测下QPS会明显下降因为磁盘fsync的耗时远高于内存操作主要适合对数据安全要求极端、写入量又小的场景实际生产中用得很少。everysec表示每秒执行一次fsync。意味着最多丢一秒内的写入数据。这是性能和数据安全平衡得最好的方案也是生产环境最常用的配置。Redis官方默认就是这个值大厂基本也都用它。no表示不主动执行fsync由操作系统决定什么时候把缓冲区数据刷到磁盘。这种方式性能最好但丢数据的风险完全交给操作系统最坏情况下可能丢失数秒甚至更长时间的数据。实际用下来我的建议是没有特殊理由就直接用everysec。除非你做的是财务流水这类完全不允许丢数据的业务那可以考虑always但要接受性能大幅下降的代价。而no这个选项我实在想不出什么场景值得推荐。3.2 AOF的rewrite机制为什么日志文件需要瘦身AOF有个天生的问题文件会无限增长。比如你对同一个key执行了1000次incrAOF文件里就会记录1000条incr命令。恢复时要把这1000条全部重放一遍。更糟糕的是很多value可能早被覆盖了老命令重放也没意义纯粹是垃圾。解决思路就是AOF rewrite。Redis会扫描当前内存中的完整数据集生成一组最精简的写命令来代表当前状态。以上面那个例子来说rewrite后可能只生成一条set命令把最终值写进去即可。rewrite的触发也分手动和自动。手动用bgrewriteaof命令自动由配置控制。auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb含义是当AOF文件大小超过上一次rewrite后大小的100%即翻倍时触发自动rewrite同时文件大小不得低于64MB防止频繁触发。rewrite本身也是fork子进程去做的原理和bgsave类似。一个常见的误区是打开了AOF后以为只要不管它就行。实际上如果rewrite配置不合理AOF文件会膨胀到几十GB磁盘告警不说恢复时重放也要花很长时间。另外要提醒一点在AOF rewrite期间Redis会把新的写命令同时缓存在rewrite buffer里子进程完成rewrite后再把缓冲区里的增量命令追加到新AOF文件。这一步骤是阻塞主进程的所以太大也会造成秒级阻塞。3.3 AOF的优缺点与适用场景AOF最大的优点就是丢数据少。everysec模式最多丢一秒always模式基本不丢。它的日志是纯文本格式可读性好出了故障甚至可以直接打开文件查询写入了哪些命令排查问题时比较直观。缺点是文件体积大恢复加载速度慢。哪怕做过rewriteAOF文件一般也明显大于同数据量的RDB文件。加载时逐条重放命令数据量大时启动时间可能以分钟计。另外同样的AOF文件如果配置了混合持久化恢复速度会快很多这点后面专门讲。这里要说一个隐藏得很深的坑AOF文件在追加写过程中如果遇到Redis异常退出、磁盘故障或者机器断电文件尾部可能出现不完整或者损坏的数据。Redis提供了aof-load-truncated配置项默认yes表示加载时遇到截断的AOF文件会自动截掉尾部损坏部分并正常启动。但在主从环境下从节点加载了不完整数据可能和主节点数据不一致。所以这个参数在极端严格要求一致性的场景里要慎重必要时改为no并配合人工介入。AOF适合对数据安全要求高的业务比如用Redis存订单状态、分布式锁、计数类数据或者当缓存后面的数据源重建成本很高时AOF的最多丢一秒就是底线保障。4. 混合持久化重启恢复把快照和日志拼起来4.1 混合持久化的原理和配置既然RDB恢复快但丢数据多AOF丢数据少但恢复慢那能不能结合起来Redis 4.0开始支持混合持久化。配置项是aof-use-rdb-preamble yes开启之后AOF文件的结构变了前半部分是RDB格式的二进制快照数据后半部分是从快照时间点到当前时刻的增量写命令仍然以AOF格式追加。这样设计的好处很明显。恢复时先加载文件头部的RDB数据直接得到大部分数据然后重放尾部少量增量命令速度比纯AOF快一个数量级。数据安全方面由于增量部分仍然以AOF方式记录everysec模式下最多丢一秒数据。我曾经做过一个对比测试同样30GB的数据集纯AOF文件恢复耗时接近500秒开启混合持久化后恢复耗时降到70秒左右。这个差距在故障切换、重启扩容时就是生与死的区别。这里有个容易踩坑的点混合持久化只在开启AOF的前提下生效。如果你只是开了RDB没开AOF那混合持久化配置是无效的。生产环境要做好配置联动。4.2 重启恢复流程与加载优先级现在把问题聚焦到Redis重启后数据怎么回来。Redis重启时加载持久化文件的优先级是AOF优先RDB兜底。具体逻辑是如果开启了AOFRedis会优先尝试加载AOF文件作为数据恢复来源只有AOF没开启时才尝试加载RDB文件。启动日志里面会打印相应的加载信息一眼就能看出当前加载了哪种文件。有人会问如果RDB和AOF文件都有那这两个文件里的数据可能不一致为什么不两个都加载取个并集或者交集答案是因为AOF文件包含了从RDB快照时刻之后的所有增量命令理论上数据比RDB更新加载AOF就够了。如果两个文件都加载反而可能把旧数据覆盖新数据逻辑上说不通。补充一个冷门但重要的细节开启混合持久化后RDB文件仍然会正常生成也就是dump.rdb还在。这样你可以继续用RDB做冷备归档。每次Redis正常关闭或者触发自动save条件RDB都会更新。万一AOF文件损坏无法恢复还有RDB兜底。4.3 四个实践场景的持久化选型到底该开RDB还是AOF还是两个都开这个问题没有统一答案但结合场景可以给出清晰的方向。纯粹做缓存、数据丢了能重建、能接受短期冷缓存穿透的RDB就够了。这种场景追求的是快照恢复速度和低内存开销不需要AOF每秒钟多刷一次盘。数据敏感、比如存了用户会话或者业务状态、不能丢超过一秒的必须开AOF而且建议配合混合持久化。同时保留RDB作为冷备双保险。读写量极大、对性能极度敏感、但又希望尽量少丢数据的混合持久化加everysec是当前最优解。RDB也可以关掉或者把自动触发放宽减少fork频率。还有一种特殊场景为了做数据迁移或分析只需要一个静态数据文件。这时候手动执行一次bgsave或者save拿到RDB文件即可不需要持续性持久化。值得一提的是主从复制架构下持久化的压力主要在从节点。通常的做法是在从节点上开启持久化主节点关闭或调低持久化频率减少主节点fork次数。主节点挂了从节点提升时还有一份持久化的数据。这种模式下更要注意主从数据的一致性检查因为从节点持久化中断时不会影响主节点对外服务但重启后数据可能滞后。5. 生产环境配置实践与问题排查实录5.1 一套可以直接抄的配置模板我在多个项目中使用过一套比较稳妥的持久化配置这里分享出来供参考实际使用时按机器规格和业务要求微调。# 开启混合持久化前提是AOF处于开启状态 aof-use-rdb-preamble yes # AOF基础配置 appendonly yes appendfilename appendonly.aof appendfsync everysec auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # RDB自动触发放宽频率以减少fork频次 save 900 1 save 300 10 save 60 10000 dbfilename dump.rdb dir /data/redis # 安全兜底 no-appendfsync-on-rewrite yes aof-load-truncated yes有几个点解释一下。no-appendfsync-on-rewrite这个参数容易被忽略。它的作用是在AOF rewrite期间暂停fsync避免大量写盘和rewrite子进程IO竞争。代价是这段时间内如果宕机可能丢超过1秒的数据。这个取舍我认为值得因为AOF rewrite期间盘IO压力本来就大如果再强制fsync很容易拖慢主进程。如果你的业务一分一毫都不能丢那就保持这个参数为no但要接受rewrite期间性能变差。data目录建议单独挂载磁盘别和系统盘放一起。Redis持久化文件IO密集如果系统盘满导致写不进去Redis会直接报错退出这个是血泪教训。磁盘至少预留当前数据量2倍的空间因为bgsave和AOF rewrite都是写临时文件再rename空间不足会在最后一刻才暴露失败。5.2 高频故障RDB失败、AOF损坏、重启加载慢先说RDB fork失败。常见原因是内存不足fork申请页表失败日志里会有类似Fork error的信息。排查方向是看机器内存余量和bgsave期间COW内存占用必要时限制Redis maxmemory留出足够缓冲。AOF文件损坏的报错常见于机器异常断电后重启。Redis启动时如果检测到AOF文件尾部不完整默认配置aof-load-truncated yes会自动截掉尾部并启动。但要注意有些场景截掉的部分正好是至关重要的新数据此时应该先备份损坏文件再用redis-check-aof工具修复。修复思路是找出文件中损坏的位置截断到最后一个完整命令为止。工具会输出修复结果之后重启加载即可。重启加载慢是运维里最常见的抱怨。排查思路依次是确认当前加载的是AOF还是RDB查看启动日志如果加载AOF文件是不是没有做过rewrite导致体积巨大如果加载RDB检查数据量是否本身几十GB以上。优化方向就是前面讲的混合持久化把RDB头部塞进AOF大幅减少重放量。还有一招在Redis启动时辅以--daemonize no配合日志输出能看到加载阶段的实时进度。还有一个很隐蔽的坑磁盘容量充足但AOF文件重命名失败导致的写入中断。Redis在rewrite完成后会先写好临时文件再通过rename覆盖旧AOF文件。如果这一两步之间主进程仍在写旧文件可能因为文件句柄问题导致新文件不完整。遇到写入中断日志优先检查磁盘空间、目录权限以及是否配置了不一致的dir路径。5.3 数据备份与恢复的实操经验持久化配置好不代表万事大吉。做过运维的都明白越重要的数据越要定期做恢复演练。我实践中的备份策略是每小时做一次bgsave把当前的dump.rdb增量传输到远端存储保留最近7天的版本每天凌晨做一次AOF文件归档和RDB一起存放。如果业务数据量很大可以只在凌晨归档一次AOF白天的备份以RDB为主。恢复演练建议每个月做一次。挑一台闲置节点上传备份的RDB和AOF文件启动Redis实例观察加载时间、数据量是否与业务预期一致。这一步最能暴露备份不完整的问题。曾有位同事备份脚本一直是成功的某天故障恢复时才发数据整体缺了一大块——原来是备份用的dump.rdb路径写错了一直在备份一个空目录。定期演练能提前发现这类低级但致命的错误。平时监控方面关注三个指标RDB文件生成时长、AOF文件当前体积、最近一次rewrite时间。这三个指标突然异常往往预示着持久化链路出问题。监控告警建议通过已有的监控平台接Redis的info persistence信息不要等故障了才去翻日志。5.4 持久化的进阶思考追求不丢失的边界聊完实操说一点进阶的内容。很多人把持久化和数据不丢失画等号但其实两者之间有区别。持久化保证的是Redis进程重启后数据还在但它不能保证极端情况下的零丢失。举个例子主节点宕机磁盘同时损坏那不管用什么持久化方案数据都丢光。这时候需要把持久化文件异地冗余或者依赖主从复制把数据分散到多台机器上。持久化保证单机数据落盘主从复制保证多机数据冗余两者配合才能把丢失概率压缩到极低。另一个边角是即使AOF配置了everysecRedis主进程在fsync间隙突然被kill -9仍然可能丢一秒数据。如果业务的确需要接近零丢失就必须接受always模式带来的性能损失或者改用外部数据库。这也是我一直强调先想清楚业务能丢多少数据再决定技术方案的原因。Redis 7.x对持久化的优化也值得关注。比如AOF文件可以支持多part结构加载时的并行化也做了不少工作。随着版本迭代持久化的性能和安全性都在提升但底层的设计哲学没有变快照做底、日志做增量、混合做加速。理解这套核心逻辑后换什么版本都能快速上手。最后分享一个我个人的习惯每次搭建Redis环境第一件事不是调缓存淘汰策略而是先把持久化配置理清楚。因为缓存淘汰策略影响的是缓存命中率这种性能指标而持久化影响的是数据在不在这种生存问题。先保证数据不丢再聊性能优化顺序不能反。