1. Redis重启后数据为何还在先看看持久化到底解决了什么问题很多人刚接触Redis时有过这样的困惑明明Redis是内存数据库为什么服务器重启之后之前写入的数据还在答案就是持久化。但如果你以为持久化只是把数据存到硬盘这么简单那后面踩坑的日子还长着。先说清楚一个基本事实Redis的数据默认是放在内存里的内存的特点是快但断电即失。如果没有任何持久化机制Redis一重启所有键值对全部清空这在生产环境是不可接受的。持久化本质上就是解决内存数据如何安全落地的问题——在合适的时间把内存里的数据以某种格式写到磁盘上等到重启时再把这些数据重新加载回内存。这里要先提一句有人可能看到了标题里那个酶字说实话我也不知道这个字是怎么混进来的大概率是复制粘贴时带进来的杂质不是Redis相关术语。不影响我们按正题来聊透Redis持久化的两个主力方案RDB和AOF以及它们在生产环境中的组合打法。先做一个全貌梳理RDB和AOF的关系可以理解为快照和日志的区别RDBRedis DataBase定期把内存中的全量数据拍一张照片存到磁盘恢复时直接加载快照文件。AOFAppend Only File把每一条写命令追加到日志文件末尾恢复时重放这些命令来重建数据。一个是定期存档一个是全程记账两者各有各的脾气也各有各的坑。下面逐个拆。2. RDB快照定期存档的机制、触发方式与隐蔽的fork阻塞2.1 RDB到底在什么时候触发RDB的核心逻辑是全量快照。它支持的触发方式有几种很多人只记得配置文件的save规则其实漏了不少细节。第一种是配置文件里的save规则。默认配置长这样save 900 1 save 300 10 save 60 10000这三行的意思分别是900秒内至少有1次写操作就触发一次持久化300秒内至少有10次写操作60秒内至少有10000次写操作。满足任一条件就会自动执行bgsave。注意这个规则是写操作次数 时间窗口的组合条件不是单看时间。第二种是手动触发。通过命令执行127.0.0.1:6379 SAVE 127.0.0.1:6379 BGSAVESAVE是同步保存会阻塞Redis主进程期间所有客户端请求都无法处理线上环境基本没人敢直接用。BGSAVE是后台保存fork一个子进程来做实际的数据落盘主进程还能继续服务。平时手动备份、运维操作一律用BGSAVE。第三种是关闭时自动触发。如果配置了save规则且没有禁用RDBRedis正常关闭时会执行一次持久化把当前数据存成RDB文件。这个默认行为很多人不知道但它其实很重要——意味着你正常关机时数据基本不丢。2.2 快照实现原理fork 写时复制COWRDB背后的核心机制是fork。BGSAVE执行时Redis主进程会fork出一个子进程子进程拥有主进程内存页的一份共享副本然后子进程负责把数据写入RDB文件。这里有个关键点fork出来的子进程并不会复制一份完整的内存数据而是和父进程共享同一份物理内存页。只有当主进程在fork之后收到写请求、需要修改某个内存页时才会触发**写时复制Copy-On-WriteCOW**机制——把这个页复制一份出来给主进程改子进程仍然看到的是fork那一刻的旧数据。所以RDB快照的一致性问题是这样解决的子进程从头到尾看到的都是fork瞬间的数据状态主进程的修改完全不干扰它。这意味着即使写RDB文件写到一半有大量新数据写入快照文件里的数据仍然是那一刻的全量数据一致性是有保障的。用生活化的比喻fork相当于你给家里拍了一张全家福拍照的瞬间每个人的样子就定格了。拍照之后家里就算来了客人、换了摆设照片里记录的还是拍照那一刻的场面。RDB的快照文件就是Redis在某个时间点定格的全家福。2.3 你以为RDB只占用一份内存COW的翻倍误解很多人对RDB有个误解觉得BGSAVE期间内存占用会翻倍因为要复制一份完整数据。实际上COW机制下只有主进程后续修改的内存页才需要复制如果BGSAVE期间几乎没什么写请求那额外内存开销是很小的。但反过来说如果在快照执行期间写流量很大主进程会不断触发内存页复制内存占用曲线会明显上涨。我在实际生产里见过一台内存使用率本来就到了80%的实例在BGSAVE期间内存直逼95%的情况。所以判断RDB是否危险不是看它平时占多少内存而是要看fork之后的内存写入速率。还有一个隐蔽的问题fork本身是阻塞主进程的。fork需要拷贝进程的页表等信息内存越大fork耗时越长。实测过一个内存16GB的实例fork耗时大概在300~600毫秒这期间Redis是无法处理任何请求的。如果实例内存到了上百GBfork耗时可能到秒级那就真的会造成请求阻塞了。怎么观测fork耗时用这个命令127.0.0.1:6379 INFO stats输出里有一个latest_fork_usec字段显示最近一次fork消耗的微秒数。如果这个值经常超过1000000即1秒就要认真评估是否需要降低单实例内存规模或者考虑把大实例拆小。2.4 RDB的硬伤两次快照之间的数据窗口RDB最大的问题就是数据丢失窗口。它本质上是定期存档那在两次存档之间写入的数据Redis一旦宕机就全丢了。举个例子配置了save 900 1那么最坏情况下你可能在刚刚写完一条数据后就宕机这条数据就没了或者更常见的情况上一次快照是10分钟前这10分钟里写入的所有数据全部丢失。对缓存场景来说丢一点数据问题不大——本来缓存丢了重新从数据库加载就行。但如果Redis里存的是需要持久保障的业务数据比如订单状态、用户余额、消息记录那RDB这种定期存档的思路就不够用了。这时候就要请出AOF。3. AOF日志每条命令都记下来但你怎么写决定了丢多少3.1 AOF的工作方式与伪即时持久化AOF的思路跟RDB完全不同它不拍快照而是把每一条引起数据变化的写命令SET、LPUSH、DEL、INCR等追加到一个日志文件末尾。重启时Redis把整个AOF文件里的命令从头到尾重放一遍就能把数据恢复出来。相当于你开了一家店RDB是每周拍一次库存照片AOF则是每笔进出货都记在账本上。账本记得越细丢失越少但账本也会越写越长。有个容易误会的点AOF并不是每条命令写进去就算持久化完成了。写命令先到Redis主进程的内存缓冲区然后根据配置的写回策略决定何时真正fsync到磁盘。这个策略就是AOF的appendfsync参数它直接决定了数据最多丢多少。3.2 appendfsync三种策略always、everysec、no配置项在redis.conf里appendfsync always # 或 appendfsync everysec # 或 appendfsync no三种策略的取舍要拎清楚策略写入时机宕机最多丢失性能影响适用场景always每条写命令都同步fsync到磁盘0条最多丢一条正在写的命令明显变慢吞吐下降对数据极度敏感的金融级场景everysec每秒批量fsync一次最近1秒内的写命令性能损耗较小大多数生产环境的默认选择no由操作系统决定何时落盘不确定可能丢很多性能最好对数据丢失容忍度高的缓存场景我在实际项目里几乎只用everysec。always的代价很多人低估了——每条命令都落盘写性能可能直接腰斩甚至更低尤其是小命令高并发的场景比如秒杀扣减、频繁INCR操作。不过要说一句公道话always虽然慢但它是唯一能做到进程级别的零丢失的策略前提是你的业务能接受这个性能开销。还有个执行细节要注意everysec的fsync是后台线程异步做的所以在极端情况下主进程写入了命令但后台线程还没来得及fsync这时机器断电那1秒的数据就没了。文档上说的最多丢失1秒数据是理论值实际上磁盘抖动时丢的数据还会多一点。3.3 AOF文件膨胀问题与重写机制AOF的致命缺点是文件无限增长。你执行了100万次INCR同一个keyAOF文件里就有100万条INCR命令文件可能几十GB而实际数据就一个整数。更麻烦的是恢复时要重放成百上千万条命令启动速度慢得让人抓狂。解决办法是AOF重写rewrite。重写的核心思想并不去动现有的AOF文件而是直接基于当前内存中的数据状态生成一份新的、精简的AOF文件把001这个key最终的值写成一条SET命令把那些历史中间态命令全部省略。手动触发重写用命令127.0.0.1:6379 BGREWRITEAOF生产环境一般配置了自动重写相关参数有两个auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb意思是AOF文件比上次重写时的体积增长了100%时触发重写且文件至少达到64MB才启动自动重写。这两个条件都满足了才会重写避免频繁重写影响性能。重写的底层机制也是fork子进程来做同样有阻塞风险跟BGSAVE是一个级别的。所以即便你完全不用RDB、只开AOFfork的开销也一样存在。3.4 AOF加载命令重放的两个坑AOF恢复是重放命令听起来简单实际有两个坑需要注意。第一个坑是文件损坏。机器异常断电、磁盘满都可能让AOF文件尾部出现残缺命令。Redis默认遇到这种情况不会直接拒绝启动而是会打日志。你自己要决定怎么处理。Redis提供了一个修复工具redis-check-aof --fix appendonly.aof它会扫描整个文件把有问题的命令剔除掉。注意这个操作会修改文件内容所以修复前先备份原文件。修复之后可以正常启动但被剔掉的那些命令对应的数据就丢了。第二个坑是加载耗时。一个5GB的AOF文件重放完可能需要十几分钟甚至更久这期间Redis虽然不会拒绝客户端连接但实际处于不可用状态。生产环境里遇到过AOF文件巨大、重启恢复要半小时的情况对可用性影响很大。这也是后来混合持久化方案要解决的问题之一。4. 混合持久化RDB和AOF不是二选一而是可以组合的4.1 为什么Redis 4.0要引入混合持久化聊到这里你会发现RDB和AOF各有各的好RDB恢复快文件体积小但丢数据窗口大。AOF丢数据少但文件大恢复慢。那能不能各取所长Redis 4.0给出了答案混合持久化。简单说就是AOF文件的前半部分存一份RDB格式的二进制快照后半部分继续追加AOF增量日志。这样重启恢复时先加载RDB部分快速获得一个全量数据基础再重放后面的AOF命令补齐增量数据。配置开关aof-use-rdb-preamble yesRedis 5.0及以后这个选项默认就是yes所以基本上不用手动改。需要留意的是如果你的Redis升级到4.0以上之后AOF文件开头会出现REDIS魔数标志这正是混合持久化写入的RDB格式前缀。4.2 混合持久化的收益恢复速度和丢数据窗口的平衡混合持久化带来的实际收益我直接说两组真实对比。假设一个AOF文件10GB全量命令重放纯AOF模式大概需要20分钟而混合模式下RDB格式前缀部分加载可能只要1~2分钟后面的AOF增量部分通常只有几百MB甚至更小重放也就几分钟的事。整体恢复时间能缩短一个量级。数据丢失方面混合模式仍然遵循AOF的appendfsync配置。如果用的是everysec仍然最多丢1秒左右的数据。也就是说混合持久化没有牺牲AOF的数据安全保障只是把恢复速度拉快了。这里要补充一个细节混合持久化里的RDB快照是在AOF重写时由子进程生成的。也就是说每次触发BGREWRITEAOFRedis内部会先写一份当前数据的RDB格式快照然后再开始记录重写期间的增量命令。相比纯AOF重写生成文件的速度反而更快因为二进制写入比记录一条条文本命令要紧凑得多。4.3 到底选RDB还是AOF别让配置都在默认状态很多人在网上问Redis持久化到底用哪个答案其实是看你的业务容忍丢多少数据。我整理了一个选型判断逻辑可以直接套用纯缓存场景数据可以从数据库/上游重算关掉AOF保留RDB甚至RDB也可以关追求极致性能和简单运维。业务数据落Redis比如排行榜、计数器、分布式锁、会话数据必须开AOFappendfsync用everysec同时开混合持久化加快恢复。金融级、不允许丢数据appendfsync用always但要有心理准备性能开销大且最好评估是否真的适合把这类数据放在Redis里。多实例的从库从库可以关闭持久化或只用AOF数据从主库同步。但要注意从库全量重同步时如果主库没有RDB文件会同步失败。所以一般建议主库至少保留RDB能力。最怕的是哪种情况Redis装了但持久化配置全部默认既开着RDB也开着AOF却不清楚两者之间的交互逻辑。默认配置下Redis 5.0RDB和AOF同时开启重启时Redis优先加载AOF文件——因为AOF数据更完整。很多人不知道这个优先级排查问题时容易被搞懵。5. 生产环境持久化配置实战从参数到复盘一份可以直接抄的作业5.1 一套经过验证的基础配置模板直接给一份我常用的生产配置模板各位根据自己的内存规模和业务容忍度微调# RDB配置 save 3600 1 save 300 100 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump-6379.rdb dir /data/redis/persist/ # 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几个容易被忽略但很重要的点stop-writes-on-bgsave-error默认yes含义是如果BGSAVE失败比如磁盘满Redis会拒绝写请求。这个设计很反直觉——存储故障时居然不服务写入但它的逻辑是既然持久化都失败了再写入只会加剧数据丢失风险不如及早暴露问题。在磁盘监控完善的团队这个默认值没问题但如果你的运维能力弱这个配置会导致磁盘满时业务全部报错的事故。dir配置RDB和AOF文件的存储目录必须单独规划不要放在系统盘更不要放/tmp。最好放到独立的数据盘同时给这个目录做好磁盘空间监控。磁盘满导致持久化失败是生产环境Redis故障的头部原因之一。rdbchecksumRDB文件写入时是否做CRC64校验。开着会多一点点CPU开销但能在加载时发现文件损坏。默认yes不建议关。5.2 Redis 7带来的变化Multi-Part AOF如果你用的是Redis 7.0AOF的实现发生了比较大的变化——引入了Multi-Part AOF机制。原来单个appendonly.aof文件会被拆成多个文件包含基础文件manifest清单、RDB格式前缀文件、增量日志文件等。这个变动的实际意义一是在AOF重写时可以更安全地处理多个文件减少重写中途宕机导致整个AOF损坏的风险二是为未来更细粒度的持久化控制铺路。对使用者来说目录下的文件会变多变杂不要大惊小怪看到类似appendonly.aof.1.base.rdb、appendonly.aof.1.incr.aof这样的文件是正常的。Redis 7还提供了新的配置项比如可以独立控制AOF重写的最小间隔时间aof-rewrite-incremental-fsync等整体思路更精细。但从使用角度核心的appendfsync策略、重写触发条件这些概念没有变化把老的配置迁移过来基本兼容。5.3 排查链路重启后数据丢失怎么一步步定位最后分享一个实战排查过程。有一回线上一个Redis实例重启后某个业务报数据少了大约几分钟窗口的量。我当时按这个链路排查第一步确认持久化配置。连上实例执行CONFIG GET appendonly和CONFIG GET save发现AOF是关闭的只有RDB。那基本上可以断定是RDB快照窗口导致的数据丢失——上次快照之后、宕机之前写入的数据没落盘。第二步确认上次快照时间。执行INFO persistence看rdb_last_save_time字段。如果这个时间离宕机时间很远说明快照窗口非常大数据丢得多也就不奇怪了。第三步判断是否只有RDB。业务当时对数据丢失完全不能接受所以直接把AOF开启并调整appendfsync为everysec同时保留混合持久化。后续再重启丢失窗口从分钟级别降到秒级别。第四步验证AOF加载是否正常。重启后观察日志里的加载速度和是否有错误再抽查关键key的值确认业务侧数据完整性恢复了预期水平。这套链路不复杂但每一步都有对应的命令和字段定位起来很快。核心思路是先判断用的是哪种持久化方案再推算理论上最多丢多少数据然后确认实际丢失量是否在预期范围内最后做配置修正。5.4 那些年踩过的其他坑最后集中写几个容易踩的坑每一个都是我实际遇到过的第一个坑两台机器之间直接拷贝RDB文件恢复忽略了版本兼容性。RDB文件格式在不同版本之间有差异用高版本Redis加载低版本的RDB一般没问题但反过来低版本加载高版本的RDB会失败。跨版本迁移时要么升级源端要么通过高版本主动做一次BGREWRITEAOF导出AOF文件来迁移。第二个坑把AOF文件用文本编辑器打开还保存过。AOF文件里包含二进制格式尤其混合持久化开启后用编辑器打开并保存会破坏文件结构导致Redis启动时根本无法加载。别手贱去改AOF文件内容要改就通过客户端命令改数据。第三个坑备份策略只拷贝当时的持久化文件不考虑一致性问题。比如直接cp正在写入的AOF文件可能拷贝到一半的文件内容是残缺的。正确做法是先执行BGSAVE或BGREWRITEAOF等命令结束后再拷贝对应文件或者用快照工具做一致性备份。第四个坑忽略latency monitor里对fork耗时的记录。如果你的Redis内存特别大fork阻塞时间可能会直接影响请求延迟。建议在大实例上开启延迟监控重点关注fork相关事件。平时没事不等于真没事有一次线上偶发请求超时排查半天最后发现就是BGSAVE触发fork那几百毫秒造成的。Redis持久化这个话题说大不大说小不小。它不像数据结构、缓存策略那样天天被讨论但一旦出事就是大事——数据丢失这种事对一个技术团队来说往往就是一场事故。把RDB和AOF的原理吃透把混合持久化的收益搞清楚再配合一套合理的监控和备份机制基本上就能做到数据不丢失这件事心里有底。最后再分享一个我个人的习惯不管Redis配置了多完善的持久化我仍然会定期把RDB文件或AOF文件备份到独立存储同时做一次恢复演练。持久化配置写得再漂亮恢复不了等于白搭。生产环境里备份的有效性永远要靠恢复来验证这个原则放到哪个系统都一样。