1. 先搞清楚一件事为什么Redis必须做持久化干这行久了被问得最多的Redis问题之一就是“重启之后数据没了怎么办”。不管你是刚开始学Redis还是在生产环境维护着一堆实例持久化策略始终是绕不开的一环。Redis默认把数据放在内存读写都快但进程一退出内存里的数据就没了所以要靠持久化机制把数据落到磁盘上。这篇文章就围绕RDB快照、AOF日志和4.0之后的混合持久化展开把机制原理、配置参数、恢复实操和生产踩坑一次说清楚。适合看这篇内容的人很明确刚接触Redis、正准备把它用进业务的新手可以在上线前就把持久化配好省得将来被“数据无故消失”折磨背过Redis面试八股但没真正理解参数含义的人看完能知道这些设计到底在解决什么问题已经在生产环境扛着在线服务、却被重启丢数据搞怕过的运维和开发可以直接对照后面的配置和排查清单去落地。1.1 内存数据库的宿命与两类持久化方案Redis之所以快是因为所有数据都直接操作内存但这个设计天生有个问题内存断电即失、进程退出即清空。你可以把Redis实例想象成一个记性特别好的账房先生白天算账飞快所有账目都在脑子里但一到打烊休息脑子里的内容就全消失了。为了解决这个问题Redis提供了两条落盘路径RDB快照和AOF日志。RDBRedis DataBase是每隔一段时间把内存里的数据整体生成一份二进制快照文件相当于给账本拍一张照片存档。AOFAppend Only File则是把每一条改变数据的写命令追加记录到日志文件里相当于把每一笔交易都记进流水账本。两者各有取舍写命令本身记录的精度更高快照恢复起来更快所以生产环境经常搭配着用。很多人只知道“Redis有持久化”却分不清这两种文件到底存的什么。简单记忆就是RDB文件里是某个时间点的数据本体AOF文件里是一个又一个写命令的序列。理解了这一点后面所有配置和故障排查都有抓手。默认安装完Redis后配置里其实已经带了一套RDB触发规则但AOF默认是关闭的这也是很多人在没配任何持久化的情况下“重启数据居然还在”的原因。1.2 持久化文件、备份与灾难恢复的边界在深入配置之前必须先画一条边界持久化文件解决的是“进程退出后数据不丢”备份解决的是“机器损坏、磁盘故障、误删文件之后还能恢复”。两者不是一回事。持久化文件通常就在Redis实例所在的机器上如果这台机器整个坏了持久化文件也跟着没。所以成熟的生产环境里持久化是基础定时把持久化文件归档到异地、上传对象存储才是备份。主从复制是另一条独立的防线主节点挂了可以有从节点顶上而且从节点本身也会生成自己的持久化文件。但有主从不代表可以不开持久化如果主从都依赖内存一旦同时重启照样全丢。我的建议是把持久化、主从、冷备当成三个互补的机制而不是互相替代的方案。后面第5章会专门讲怎么把这三件事串起来做恢复演练先记住这个边界后面所有的操作都不会跑偏。2. RDB快照够快但赌的是“最后一次成功”RDB的好处是文件紧凑、恢复极快但它有一个天然短板只有在触发快照的时间点数据才会被固化而从上次快照到崩溃之间的数据理论上都可能丢。你要问生产中那些“重启丢数据”的案例大部分都是栽在这个时间差上。2.1 RDB在什么时刻拍快照先看触发方式。手动触发有两条命令save和bgsave。save是同步执行直接在主线程里把数据写进文件期间Redis完全阻塞生产环境千万别这么玩我见过有人调试时不小心执行save几万QPS的实例瞬间冻住十几秒。bgsave才是正路它会fork一个子进程去做磁盘写入主线程继续服务读写请求。自动触发看配置文件里的save规则。默认是save 900 1 save 300 10 save 60 10000很多新人理解这三行有偏差它的真实含义是900秒内至少发生1次写操作就触发一次bgsave300秒内至少发生10次写操作就触发一次bgsave60秒内至少发生10000次写操作就触发一次bgsave。注意关键词是“且”是“在N秒内达到M次写才触发”而不是“每隔N秒就一定会触发”。如果你的业务在900秒内确实没有1次写那RDB就可能很久不落盘这是设计如此不是配置坏了。这个规则设置得很讲究。写频率越高快照间隔就可以越短因为数据变化快晚一点拍就可能丢一大批写频率低的场景即使间隔拉长丢失的数据量也相对可控。所以生产环境里如果你的实例写入量极低可以适当把save 900 1改成save 3600 1减少无谓的磁盘IO和fork频率如果写得很猛可以补一条save 30 100把丢失窗口压得更小。改完之后记得用config rewrite或直接改配置文件并确认配置能真的生效。2.2 fork背后的写时复制原理bgsave之所以比save安全依赖的是操作系统的fork能力。fork之后会创建一个子进程子进程看到的内存页在fork那一刻被定格主进程随后继续处理新的写命令。这里有个关键机制叫写时复制Copy-On-Writefork的时候并不会把整个内存复制一份而是父子进程共享同一份物理内存页只有当主进程要修改某个内存页时才把这一页复制一份再改保证子进程手里的快照始终是fork那一刻的旧数据。这个机制解释了三个生产现象。第一fork瞬间会有一个短暂的主线程耗时虽然比save要短得多但内存越大fork越疼实测里几十GB内存的实例fork一次就可能让延迟从毫秒级跳到几十毫秒所以大实例不能放任bgsave在业务高峰随意触发。第二bgsave期间主进程持续写入但快照不受影响因为它是fork时刻的定格画面。第三如果bgsave期间有大量写操作内存页复制开销会明显抬高这时候实例的内存可能短暂飙升如果本身内存就吃紧bgsave反而可能加剧风险。配置文件里还有几个跟RDB相关的参数。rdbcompression yes会压缩RDB文件压缩要消耗CPU但能显著减少磁盘空间和网络传输量我建议保持默认。stop-writes-on-bgsave-error同样值得在意它默认是yes含义是如果bgsave因为磁盘满等错误失败Redis会直接拒绝写命令而不是假装没事。这个设计看起来很粗暴但其实是保护数据让你立刻发现持久化出了问题总比数据悄悄丢到崩溃时才发现好。2.3 RDB的优劣势与适用场景把RDB和AOF在关键维度上做个对比选型的时候思路会清晰很多对比维度RDB快照AOF日志文件形态二进制压缩快照文本形式的写命令日志恢复速度直接加载数据文件快逐条回放命令慢丢失窗口受save规则控制可能丢几分钟甚至更久受刷盘策略控制多数情况最多丢一秒文件增长大小基本稳定持续膨胀依赖重写机制适用场景冷备、全量同步、可容忍丢失的缓存对数据一致性要求更高的业务场景我之前维护过一个纯缓存集群里面全是可以被容忍偶尔重新生成的商品信息这类场景单独用RDB完全够用既省事恢复也快。但如果同一个实例里还存了用户资产、订单流水这类不想丢的数据RDB单独撑着就很危险。那些被“重启丢数据”坑过的人十有八九就是没意识到RDB的丢失窗口到底有多大。真的到了那一步RDB能救你一下但别指望它做主力保障。3. AOF日志记流水账丢得少但别忽略 rewriteAOF的核心思路和RDB完全不同。RDB拍的是“某个时刻的数据全貌”AOF记的是“每次数据变化的操作命令”。只要命令没丢数据就能重放出来。3.1 AOF记录的是什么开启AOF之后Redis会把每个会修改数据的命令按顺序追加到appendonly.aof文件末尾。比如执行SET name zhangsanAOF文件里就会多一行对应的命令记录。读取数据的GET不会进AOF没改变数据的写命令也不会产生额外冗余记录所以AOF的语义很简单逐条回放AOF里的命令就能还原出最终的内存状态。AOF最关键的设计是刷盘策略由appendfsync参数控制它决定了写命令先落到操作系统的内存缓冲区、还是直接强制写入磁盘。三个选项分别是参数值刷盘时机崩溃丢失窗口性能影响always每条写命令都执行fsync强制刷盘0条命令最慢QPS明显下降everysec每秒执行一次fsync最多1秒内的写命令折中生产常用no不主动fsync交给操作系统决定不确定可能几十秒甚至更多最快但风险不可控always听起来最美但实测中它对写入性能的拖累非常大因为每次写命令都强制磁盘同步磁盘IO会成为瓶颈。而everysec在正常服务器上用起来性能损耗基本可以接受最多丢一秒数据对绝大多数业务都在可接受范围内。no则适合那些对持久化要求极低、只求速度的临时场景或者你确定数据在几秒内丢失也无所谓的缓存。我这几年经手的生产实例几乎清一色用的everysec。3.2 AOF重写为什么必须做AOF是追加日志只要业务一直写文件就会一直涨。一个高频写服务的AOF文件涨到几个GB是分分钟的事到了那个量级重启时回放命令会慢到让人怀疑人生。所以Redis设计了重写机制也就是bgrewriteaof把当前数据库里的数据以最精简的写命令形式重新生成一份新的AOF文件。重写不是“在旧AOF文件上删删减减”而是基于当前内存数据重新构造。自动触发的条件由两个参数控制auto-aof-rewrite-percentage默认100auto-aof-rewrite-min-size默认64mb。触发条件是当前AOF文件大小相比上次重写后基准大小翻了一倍并且当前文件已经超过64MB才触发。换句话说AOF从32MB涨到64MB不会重写从64MB涨到128MB就可能触发。这是为了防止小文件频繁重写消耗性能又确保大文件不会无休止膨胀。重写过程有一个很容易被忽略的细节重写期间主进程仍在接收新写命令这些命令不能丢。所以Redis会同时往旧的AOF文件里继续追加日志另外再开一个缓冲区记录重写期间的新命令。当子进程把新的AOF主体文件生成好后Redis会把缓冲区里积累的命令追加到新文件尾部最后用新文件原子替换旧文件。这个双缓冲设计保证了重写过程对线上服务完全无缝旧文件始终可用新文件最终完整。理解了这套机制再看到重写期间日志信息里aof_rewrite_buf相关的指标时就不会一头雾水。3.3 AOF的局限与注意点AOF的短板也需要心里有数。首先是文件通常比RDB大因为同一条数据被反复修改时RDB只记录最终值AOF则把所有历史写命令都按顺序留着直到重写才压缩。其次是启动加载时Redis要逐条回放全部命令同样一份数据纯AOF加载经常比纯RDB慢得多。我在一次恢复演练里做过粗略对比几GB的AOF加载时间可以用分钟计算而同样数据的RDB文件十几秒就搞定。另外always策略下每条命令都fsync写放大很明显并发写入场景下QPS掉一半都不稀奇。还有一些边界情况AOF文件可能因为磁盘故障、断电、误操作被截断或损坏此时Redis默认会尝试按配置处理比如aof-load-truncated yes会允许加载文件里能解析的部分。要牢记一点AOF开启后它就成了重启时的事实数据源如果文件损坏又没修复启动就会失败或者只恢复出一部分数据这种情况必须走工具修复不能简单删了了事。修复方法我在第5章展开讲。4. 混合持久化4.0之后的生产标配如果你既要RDB的加载速度又想要AOF的低丢失窗口Redis 4.0开始提供的混合持久化就是答案。我自己的生产环境在升级到4.0之后基本都是开启混合模式。4.1 为什么混合持久化能兼顾恢复速度与丢失窗口混合持久化由参数aof-use-rdb-preamble控制开启后AOF文件的结构会变成两段式前半段是RDB格式的二进制快照记录启动时数据集的完整状态后半段是RDB快照之后产生的AOF增量命令。加载的时候Redis先把前半段RDB部分直接载入内存再回放后半段AOF命令把数据补齐到最新。这里做一个很直观的对比。纯RDB模式下恢复最快但可能丢很多数据纯AOF模式下最多丢一秒数据但加载慢混合模式下既有RDB的快速装载又有AOF的低丢失窗口代价是文件格式比纯AOF复杂管理工具需要兼容。好消息是Redis自带的恢复逻辑、主从复制、甚至redis-check-aof工具都理解和处理这种格式所以生产上基本不需要额外操心。有一点要提醒混合持久化本质上是AOF的进化形态所以它的启用前提仍然是appendonly yes。如果你只开RDBaof-use-rdb-preamble这个参数是不起作用的。另外如果你手里还有低版本Redis实例比如3.x、2.x配置文件里根本不存在这个参数从旧版本升级到新版本的时候要注意兼容性别直接把新版配置丢给旧版。4.2 生产环境推荐的一档配置直接给一份我常用的核心配置片段逐行注释是我根据多年维护经验整理的可以直接抄但要根据端口、目录做调整# RDB相关 save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes dbfilename dump-6379.rdb # AOF相关 appendonly yes appendfilename appendonly-6379.aof appendfsync everysec no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 混合持久化 aof-use-rdb-preamble yes # 目录 dir /var/lib/redis逐条解释为什么这么配。RDB部分保留默认触发规则是为了在正常业务节奏下RDB也能稳定产出可用的快照文件这些文件既是恢复手段也是主从全量同步时的重要数据源。stop-writes-on-bgsave-error保持yes磁盘出问题时宁可让写入先报错也不能让数据在黑盒中丢失。AOF部分用everysec换性能用自动重写条件控制文件体积然后把混合持久化打开这样日常运行时有AOF的低丢失保障重启时又有接近RDB的加载速度。有人会问既然AOF已经这么强RDB是不是可以关掉我的经验是不到特殊场景不建议纯关闭RDB。RDB文件体积小适合做周期性冷备主从全量同步的时候Redis也会依赖RDB文件来完成数据传输甚至排查问题时一个小的RDB也比巨大的AOF好搬好分析。所以最佳实践不是二选一而是让两者各司其职。还需要注意如果你是在已运行的实例上从纯RDB切换到AOF直接用config set appendonly yes会立即开启AOF并触发一次重写生成初始文件但一定要记得同时把配置写进redis.conf否则下次启动又回到了纯RDB状态。5. 数据恢复、文件损坏与备份策略全实操配置文件写得再漂亮最后还是要落到“能不能把数据找回来”这件事上。这一章我把恢复、修复和备份的完整流程捋一遍。5.1 从持久化文件恢复数据恢复流程的核心就三步确认文件位置、放回正确目录、启动Redis观察日志。先看redis.conf里的dir参数它决定了RDB和AOF文件的存放目录。dbfilename和appendfilename分别指定两个文件名很多实例会按端口命名比如dump-6379.rdb和appendonly-6379.aof方便在同一台机器上区分。当你需要恢复数据时先把备份的持久化文件放回dir目录并确保文件名与配置一致然后启动Redis。启动日志里会出现类似Reading RDB base file on startup、Loading DB from file的过程文件越大这一步耗时越长。我遇到过有人看到日志停在这里很久直接判定启动失败其实不是是几GB的文件在慢慢加载耐心等它完成日志里会出现DB loaded from disk的字样。这里有个优先级规则必须知道当同时存在RDB和AOF文件时Redis优先加载AOF。原因很简单AOF的丢失窗口比RDB小理论上它所代表的数据状态比RDB更新自然以AOF为准。这也意味着如果你的AOF文件被打包坏了而RDB文件是好的直接启动依然会因为AOF异常而失败必须先处理AOF。这个规则很多人记不住实战里栽跟头就在这一下明明RDB备份完好重启却失败第一反应以为是配置文件错了查半天才发现AOF文件才是启动时的唯一准绳。5.2 文件校验与修复Redis自带了两个检查工具redis-check-aof和redis-check-rdb它们通常在redis安装目录的src或bin下。针对AOF文件常用命令是redis-check-aof --fix appendonly-6379.aof它会扫描AOF文件里每条命令是否完整可解析遇到被截断的残缺命令就提示修复把坏掉的部分隔离掉保留能解析的部分。操作前必须把原文件先复制一份因为修复过程会改写原文件。RDB文件同样可以检查redis-check-rdb dump-6379.rdb它会逐段校验RDB文件的完整性如果文件尾部损坏会尽量识别有效数据范围并给出报告。实际修复之前先想想丢失的数据能不能接受。fix的本质是“丢尾保头”如果截断部分刚好是最近的关键写操作丢掉一样有损失这时候就要看有没有主从节点、有没有更近的备份文件兜底。还有一个和启动相关的参数aof-load-truncated。它默认是yes意思是AOF尾部有截断时Redis会忽略尾部问题直接启动。测试环境这么配省事但生产环境我强烈建议改成no。原因很直白静默忽略掉的尾部命令可能正是你最需要的那几秒数据。改成no之后Redis会因AOF不完整拒绝启动强制你走修复流程或者找回备份看起来更麻烦但至少你不会在毫不知情的情况下丢失数据。5.3 备份体系怎么做才稳持久化是地基备份是高层建筑。我的做法是建造三层备份网。第一层持久化文件本身Redis实例不管怎么重启数据都在第二层定时归档写一个cron任务每小时把dir目录下的RDB文件复制到实例之外的磁盘目录每天把AOF文件打包上传到对象存储或另一台机器第三层主从复制让从节点承担一部分读取压力在主节点硬件故障时能快速切换。三层各有职责缺任何一层都可能在某类故障中裸奔。归档脚本不用写多复杂核心逻辑就是cp加时间戳再用Rclone或云厂商的客户端往对象存储上传。真正的重点在于演练。我过去一年至少安排过两次完整的恢复演练把一台测试机的Redis数据清空然后只从备份文件里把数据恢复到一台新实例上记录耗时和数据完整性。没有演练过的备份体系我只能说它“看起来存在”真出事时能不能扛得住完全是另一回事。另外如果你在Kubernetes里部署Redis特别要注意持久化文件与Pod生命周期绑定的问题默认容器内路径随Pod一起销毁要挂载PVC或使用共享存储否则Pod被重启后落盘的持久化文件也会跟着消失。6. 生产环境踩坑实录与排查清单到这一章之前都是理论加操作但从实际生产来看每个坑后面都站着一次线上事故。我把这些年碰到次数最多的几类问题拿出来按症状、原因、排查路径整理成清单方便你直接对着查。6.1 高频故障fork阻塞、大key拖垮bgsave症状很典型某个时间点Redis主线程延迟突然飙高客户端大量超时日志里能看到bgsave相关的记录。这时候先用info stats看一眼latest_fork_usec这个值表示最近一次fork耗时单位是微秒。如果这个值在几万、几十万微秒也就是几十到几百毫秒级别那延迟飙升很可能就是fork引起的。再配合redis-cli --bigkeys去扫描大key。为什么大key会放大fork的问题因为fork时主进程要复制被修改的内存页大key如果频繁被写对应的内存页复制开销就大bgsave期间的写放大更明显。我处理过一个实例某业务把几MB的list当作缓存对象每次更新都要修改大片内存bgsave期间主线程明显卡顿。解决思路通常是三类业务上拆分大key让单个对象变小调整持久化触发规则避开业务高峰自动bgsave如果内存已经很大考虑集群化分摊数据。这里没有银弹得按实际场景组合着用。6.2 AOF文件无脑增大的隐形杀手与解决路径另一个常见事故是磁盘告警翻到监控里一看AOF文件占了几个GB甚至更大。先查info persistence里的aof_current_size和aof_base_size如果aof_current_size远超aof_base_size说明文件已经增长到触发重写的阈值以上但还没重写。排查方向有三个。第一auto-aof-rewrite-min-size是不是设置得太大了默认64MB不算大但如果你把实例当缓存、写量又高64MB很快撑爆需要手动把min-size调到1GB或更高配合percentage一起调。第二检查是否有长时间的重写失败AOF重写失败的常见原因是磁盘空间不够或者子进程被操作系统杀掉。第三看看是不是有人在误用always刷盘策略这种策略下每条命令都写盘AOF体积增长速度远超everysec。处理方式不难先手动执行bgrewriteaof把文件瘦身再把触发阈值改成符合实例量级的数值最后把磁盘空间加回来。顺带提醒这类事故如果发生在RDB写盘失败且stop-writes-on-bgsave-error为yes的场景下表现不会直接是“AOF太大”而是“写入突然报错”这时候往磁盘容量方向排查往往一查一个准。6.3 三个最容易被忽略的细节最后分享三个我在实际运维中真正被坑过、却很少出现在文档里的细节。第一关闭默认RDB配置之后主从复制的全量同步会受影响。Redis做全量同步时主节点要生成RDB文件传给从节点如果你的配置里把save全部注释掉RDB依然可以靠手动bgsave或复制机制触发但如果你不小心把配置改得过于“干净”全量同步会变得不可预期。所以即使你有主从复制也建议保留至少一条RDB触发规则。第二AOF开启后文件加载过程长得像“假死”。日志会先停在类似Reading AOF file的提示然后长时间不输出新日志CPU和内存都在涨但客户端连不上。这是正常现象不是进程卡死。判断方法是看进程是否还在工作、日志有没有新增输出而不是一看到没响应就去重启你强行重启不但救不了还可能把正在恢复的AOF文件搞出更严重的损坏。第三持久化文件本身也是敏感数据。RDB和AOF文件里存放着真实业务数据上传备份时权限要收紧Redis进程的运行用户也不要随意赋予过高的系统权限。我见过有人把dump.rdb放在任意用户可读的目录里然后又用root权限跑Redis这属于把自己暴露给风险纯没必要。我自己的习惯是每次给Redis调完持久化配置都会顺手做一件事手动触发一次bgsave和bgrewriteaof再重启一次实例确认加载时间和数据量在预期内。这个动作很笨但能提前发现90%的配置问题。持久化策略听起来是基础功课真正把它吃透需要的是在测试机上一次又一次地演练“毁掉数据再救回来”的过程。希望这篇文章能让你少走这些弯路。