1. 缓存不是加了就完事:先想清楚Redis在链路里的位置先说一个我自己见过很多次的场景:业务压力上来,数据库连接数被打满,应用层加了一个Redis缓存,结果只扛了两天,数据库的慢查询反而更多了。问题不在Redis本身,而在把缓存当成一个放数据的桶来用,没有想清楚这个桶在链路里到底承担什么角色。Redis缓存设计的第一步,不是选数据结构、不是定key格式,而是搞清楚:哪些数据值得走Redis,哪些数据放进Redis只会帮倒忙。1.1 什么样的数据才值得进Redis缓存的核心逻辑是用空间换时间,但空间是有成本的,时间也分场景。有一类数据天然适合进Redis:读多写少、访问热点集中、对短暂的不一致不敏感。举个例子,商品详情页、配置信息、用户资料这类数据,读的频率可能是写的几十倍,而且用户能接受的延迟窗口相对宽裕,就算缓存里延迟了几秒才更新,用户基本感知不到——这种就是Redis的主场。反过来,有三类数据我不建议放Redis:强一致要求极高的数据。比如资金流水、订单状态的实时流转,这些数据一旦缓存和数据库不一致,就会产生资损级别的bug。缓存引入的是最终一致,强一致场景应该直接查数据库,或者只把缓存当作加速手段,不用它参与核心判断。超大且低频访问的数据。一次全量导入的几GB历史数据,一天才被访问几十次,放Redis纯属浪费内存,这种更适合放到对象存储或者归档库。高频写且写读比接近1:1的数据。每次请求都写,缓存的价值会被写放大效应吃掉,还可能因为写后删缓存、写后更新缓存之类的操作把数据库拖得更累。我倾向于先给数据做一次分级:核心数据直连数据库,高热度读数据走缓存,冷数据走归档。分级之后再看Redis,Cache-aside(旁路缓存)的模式才立得住。1.2 引入缓存后新增的三个麻烦很多人只看到缓存带来的吞吐提升,没看到它同时引入了三个新问题:T1的不一致、缓存与DB的同步成本、以及缓存自身的故障域。不一致这块,后面会用一整章专门讲,这里先说清楚一个认知:缓存不是数据的副本,而是数据的投影。副本要求强同步,投影允许按规则延迟,设计缓存的时候心里得默认一定会有延迟,延迟多少可控才是重点。同步成本指的是:以前一份数据只写数据库,现在要写数据库再处理缓存,哪怕只是删一个key,也意味着原本单点写入变成了两段式操作。这个成本不会低到可以忽略,尤其是大key删除、批量失效的场景,处理不好会比直接查库还慢。故障域就更好理解了:Redis挂了,应用有没有兜底?缓存穿透到数据库的流量,数据库扛不扛得住?我见过一个项目,Redis集群直接宕机,业务方没有配置任何降级开关,结果数据库在几十秒内被击穿,跟着一起雪崩。缓存设计必须包含Redis不在时系统依然可用的预案,这是底线。一句话总结:加Redis之前,先画一条数据链路图,看清楚哪些请求会打在Redis上,哪些请求会穿透到DB,Redis挂了以后DB的峰值流量是多少。想明白这三件事,才谈得上后面的设计。2. 缓存方案的四个底层决策:存什么、怎么存、存多久、怎么删设计方案的时候,我习惯把问题收敛成四个决策:缓存粒度、Key命名、TTL策略、数据结构。这四个点定了,缓存的骨架基本就定了。2.1 缓存粒度:整对象缓存和字段缓存的取舍缓存粒度指的是一个key对应多少数据。最常用的是整对象缓存:把一个业务对象序列化成JSON塞进Redis,读取时整体反序列化。优点是开发效率高、代码简单,缺点是哪怕只需要其中一个字段,也要把整包数据拉出来。另一种是字段级缓存,用Redis的Hash结构把对象的每个属性存成field,读取时只取需要的字段,写入时只更新有变化的字段。优点是带宽和内存都省,缺点是代码复杂度明显上升,尤其是字段经常增删的时候,维护成本很高。我给的取舍建议很简单:对象整体小于10KB、整体读取频率高,无脑用整对象缓存;对象特别大但每次只读个别字段,优先用Hash拆分。大部分业务的详情页都适合整对象,个人资料、配置项这种大而散的场景才需要走到Hash。这里还有一个容易被忽略的点:序列化方案。整对象缓存如果是字符串拼接,体积大且解析慢;用通用序列化框架(比如JSON)可读性好,但内容冗余;用二进制序列化体积小、速度快,但排查问题时不直观。我的经验是:线上排障时能直接用Redis客户端读出可读内容的JSON方案,比那点体积差异划算得多。2.2 Key命名规范:别让线上key变成一团乱麻Key命名看起来是小事,实际上决定了你能不能快速定位线上问题。我见过最崩溃的key长这样:user_12345_20240401_info_final_v2——里面既有用户ID又有日期还有final这种历史遗留标记,出了问题根本猜不到它是哪个业务写的。我自己惯用的规范是:业务域:子模块:对象类型:业务ID[:二级ID],比如user:profile:12345、order:detail:888001。这套命名有几个好处:按前缀就能从Redis里快速扫出某个业务的所有key;从key结构就能反推数据归属,排查问题时不用翻代码;配合SCAN命令做批量分析和清理时,前缀过滤非常方便。另外两个小原则:key里不要带可变日期。缓存验证类key如果带日期,一到零点就集体失效,等于人为制造了一个雪崩点。value要有版本概念,可以在序列化内容里放一个版本号,这样即使将来反序列化结构变了,也能靠版本号做兼容。2.3 TTL过期策略:固定过期一定会出事缓存过期是一把双刃剑:不设过期,内存迟早被撑爆;设了统一过期时间,高峰期一到,大量key同时失效,数据库在零点或整点被瞬间打穿。我见过一次线上故障,就是运营活动结束后的整点,一批固定12小时过期的key集体失效,数据库IO直接冲高。正确做法是两个方向结合:基础TTL加随机扰动。比如业务TTL是600秒,实际设置时可以加一个±10%的随机偏移,600、610、630、570这样错开,避免集中在同一时刻过期。热点key不设绝对过期,改为逻辑过期。value里存一个expireAt时间戳,读取时先判断时间,如果过期了再异步去刷新缓存。这个方案对有持续热点特征的key非常有用,等真正该更新的时候才更新,而不是机械地按TTL删除。一句话:TTL不是配置项,是设计项。每个key过期时会发生什么、有多少key会同时过期、过期后谁来重建缓存,这三个问题必须在设计时回答清楚。2.4 数据结构选型:一张表看清String、Hash、List、Set、ZSetRedis的五种基础数据结构,选型逻辑其实非常固定。我整理了实际项目里最常见的选型标准:数据结构适用场景典型用途注意点String简单键值、计数缓存对象JSON、计数器、分布式锁大value会造成bigkey,注意拆分Hash对象属性、字段级缓存用户资料、配置项小字段多时节省内存,字段过多也要防bigkeyList先进先出/后进先出队列消息队列、时间线长度不可控时会造成内存增长Set去重、集合运算关注列表、标签系统超大集合的SINTER等操作耗CPUZSet带权重的排序场景排行榜、延迟队列每次写入都要维护跳表,写频率高时成本高选型的核心思路:先想清楚你对这个数据的读法是什么,再挑结构。只按ID取整体,用String;按属性取部分,用Hash;要做集合运算,用Set;要按分数排序取TopN,用ZSet——选型跟着读法走,基本不会错。还有一个内存层面的细节:Redis在元素数量较少且元素体积较小时,会用紧凑编码(比如ziplist/listpack)节省内存,但一旦超过阈值就会升级为常规结构,内存占用可能陡增。大批量写入前,最好用小规模数据测一下内存增长曲线,避免上线后发现内存翻倍。3. 穿透、击穿、雪崩:差点打垮数据库的三类事故复盘缓存领域最经典的问题就是穿透、击穿、雪崩。这三个词经常被混着说,实际上它们的成因、发生时机和处理方式完全不同。我按真实事故的排查顺序,一个一个拆。3.1 缓存穿透:查询不存在的数据,每个请求都直击数据库穿透的典型特征:请求的key在缓存和数据库里都不存在。比如一个用户疯狂请求一个不存在的商品ID,Redis查不到,数据库也查不到,那这个请求根本不会被缓存,下次再来还是直接打数据库。如果攻击者故意构造大量不存在的ID,数据库就会被打满。我的第一道防线是前置校验。对于明显非法的ID,在进入缓存之前就拦截掉,比如ID格式校验、取值范围校验、黑白名单。很多穿透攻击用的都是格式明显不合法的ID,这道防线能过滤掉相当一部分。第二道防线是空值缓存。数据库查不到时,把这个不存在的key也写进Redis,value置为空标记,TTL设短一点(比如60秒)。这样一来,同样的非法ID在60秒内不会再次穿透到数据库。注意TTL不能太长,否则业务上线了新数据,用户还要等缓存过期才能看到。第三道防线是布隆过滤器。把所有可能存在的数据ID预先生成一个bitmap,查询前先判断ID是否可能存在。布隆过滤器说不存在就一定不存在,说可能存在是有误判的,所以它的作用是挡住那些绝对不存在的请求。适合数据全集相对稳定、ID全集可以预估的场景。我实际用的组合是:前置校验过滤明显问题,空值缓存兜底大部分重复请求,布隆过滤器只在全量ID规模可控时才引入——因为布隆过滤器本身需要维护,ID全集变动频繁时,同步成本会超过收益。3.2 缓存击穿:热点key在过期瞬间的并发放大击穿和穿透最大的区别是:击穿针对的是存在但正好过期的热点key。某个key在缓存里活得好好的,所有流量都打在Redis上,数据库很轻松。偏偏在过期那一瞬间,大量请求同时发现缓存没数据,于是一起回源数据库,数据库瞬间被并发打爆。解决击穿,本质上就是解决缓存重建一瞬间的并发集中。主流方案是互斥锁。发现缓存过期时,不是立刻去查库,而是先尝试获取一个分布式锁,只有拿到锁的线程才去查库并回填缓存,其他线程短暂等待后重新读缓存。这能保证同一时刻只有一个请求在重建缓存,但代价是引入了锁的复杂度和短暂的阻塞时间。另一个思路是逻辑过期,把物理过期改成逻辑过期:key永不过期,value里存expireAt,读的时候发现逻辑过期,就异步去刷新缓存,同时先把旧值返回给调用方。这样做的好处是请求永远不会阻塞,坏处是最坏情况下,用户可能短暂读到过期数据。我个人的取舍:对读多写少、重建成本高的热点key,优先逻辑过期;对重建很快、并发窗口小的key,互斥锁更简单直接。两者不冲突,甚至可以结合使用。3.3 缓存雪崩:大面积过期之后的连坐效应雪崩和击穿的区别在于范围。击穿是一个key过期,雪崩是一大批key在同一时间段过期,或者干脆就是Redis节点宕机。不管是哪种,结果都是大量流量同时回源数据库,数据库扛不住,连锁反应拖垮整个系统。雪崩的第一道防线是过期时间随机化,也就是前面说的TTL加扰动,保证同一秒内只有少量key过期。第二道防线是多级缓存,在Redis前面加一层本地缓存,即使Redis短期不可用,本地缓存也能挡住一部分流量。第三道防线是熔断降级,当检测到数据库负载超过阈值时,直接返回降级数据或提示信息,而不是让请求继续打到数据库上。还有一个经常被忽略的雪崩场景:缓存集群重启。比如Redis集群批量重启,冷启动瞬间所有key都不在内存里,流量全部回源。这种情况下,提前做缓存预热很关键:在流量高峰到来之前,把核心数据提前加载进Redis,同时配合maxmemory策略避免内存耗尽。4. 缓存与数据库的账怎么算平:一致性的实战取舍很多团队栽在缓存的一致性问题上:数据库改了,缓存没改,用户看到旧数据;或者缓存改了,数据库没改,重启之后数据丢失。缓存一致性的本质,是你要不要为了保证实时一致而牺牲可用性和性能。4.1 双写一致性问题从哪来用了Cache-aside模式之后,一个数据更新通常涉及两步:写数据库、处理缓存。两步操作永远不可能原子完成,一定存在某个瞬间数据库和缓存是不一致的。这个不一致窗口是大是小,取决于你选择先更新DB再操作缓存还是先操作缓存再更新DB。最容易出错的写法是先更新缓存,再更新数据库。如果数据库更新失败,缓存里已经是新值,数据库还是旧值,两边直接不一致,而且这种不一致很难自动愈合。4.2 延迟双删为什么不能丢主流做法是先更新数据库,再删除缓存。删缓存的好处是:就算删完缓存后有请求回源数据库,读到的也是刚更新的新值,重新回填的缓存自然就是新值,不一致窗口极小。但先更新DB再删缓存也有一个经典坑:读请求在数据库更新前读到了旧值,并且正准备回填缓存,这时写请求删掉了缓存,但读请求随后把旧值写回去了。这个坑的解决方式就是延迟双删:删完缓存之后,隔一小段时间(比如几百毫秒)再删一次,确保旧值回填的窗口被覆盖掉。延迟双删听起来简单,实际上有几个细节:延迟时间不能拍脑袋定,要根据读请求从DB取数到回填缓存的实际耗时来定,一般取几百毫秒到一秒;第二次删除如果失败,需要有一个重试机制,否则旧值还是可能残留;延迟双删不能完全消除不一致,只是把不一致窗口压缩到极小。4.3 最终一致方案的实践边界如果业务能接受短暂不一致,最终一致是性价比最高的方案。具体做法是:应用层更新数据库之后,把需要删除的缓存key丢进一个可靠的消息队列或任务队列,由异步任务去删除对应的Redis key。这样即使删除动作失败,也能通过任务重试补上。更进一步,可以用监听数据库变更日志的方式同步缓存。通过伪装成从库订阅数据库的binlog,解析出变更的数据,再同步刷新或删除缓存。这个方案对业务代码侵入最小,適合多团队协作、不允许每个业务方自己维护缓存更新逻辑的场景。但它的代价是需要额外维护一套同步组件,而且延迟取决于日志推送的时效。大部分中大型团队优先选这个方案——因为一旦某个业务方忘了删缓存,线上就是一串诡异的不一致事故。我的实际建议是:核心链路能接受最终一致的,优先用消息队列异步删缓存;对一致性要求特别高的,用延迟双删重试把窗口压到最低;实在不能容忍任何不一致的,干脆不要用缓存。记住,缓存是来加速的,不是来当数据源的——一旦你把缓存当作唯一数据来源,一致性就是你自己埋的雷。5. 性能优化的真实抓手:内存、连接、吞吐与热key调度缓存设计做完之后,接下来才是性能优化。这里我不会讲什么Redis很快,默认就好这种话,因为真实生产环境里的性能瓶颈,往往不在Redis内核,而在使用方式上。5.1 内存优化:序列化、压缩与淘汰策略内存不是无限的,优化内存的本质是优化单key的存储成本。第一件事是选择序列化方案。同样是存一个用户对象,直接用字符串拼接可能几百字节;用通用序列化框架会带字段名,体积较大;用紧凑的二进制序列化可能只有前者的三分之一。我建议在可读性和体积之间取平衡:线上环境优先紧凑二进制序列化,排查问题时再通过临时工具转换格式查看。第二件事是压缩大value。超过几KB的字符串可以考虑压缩后再存,尤其JSON文本的压缩率非常可观。压缩带来的CPU开销通常远小于网络传输节省的时间,但对高并发低延迟场景要谨慎,先压测再决定。第三件事是设置合理的淘汰策略。Redis常用的maxmemory-policy有allkeys-lru、volatile-lru、allkeys-lfu等,大部分人默认选LRU,但热点数据场景我建议考虑LFU:allkeys-lfu能识别长期热点,避免只因为某一次突发访问就把冷数据留在内存里。选淘汰策略前,先想清楚你的缓存数据里哪些是稳定热点,哪些是一次性突发数据,策略选错了,缓存命中率会很明显地掉。5.2 bigkey和hotkey是性能的两颗雷bigkey是指单个key的value特别大(比如几MB的字符串、几万个元素的集合)。它的危害不在于内存占得多,而在于:网络传输耗时高,一个bigkey的读写可能比几百个小key还慢;删除bigkey时,主线程可能被阻塞,造成Redis短暂卡顿;集群模式下,bigkey会导致单节点数据倾斜,其他节点闲着,一个节点忙死。排查bigkey最直接的办法是用redis-cli --bigkeys扫描,它会列出大key的分布。发现bigkey之后的处理方式一般是拆分:要么拆成多个小key,要么用Hash/List结构分片存储,要么对大value做压缩。hotkey则是另一个方向的问题:某个key被超高并发访问,单节点CPU/带宽被它打满,其他key的访问反而变慢。hotkey的常见解决方案是本地缓存兜底Redis集群读写分离,但这只是缓解,如果hotkey的访问是全网级别的,更彻底的办法是在应用层做key打散,比如给热点key加随机后缀,分散到多个节点。5.3 连接池与Pipeline:把RTT压下来Redis是单线程处理命令,但网络IO是并发的,应用的瓶颈常常出现在往返时延(RTT)上。一次Redis命令的耗时可能只有0.1ms,但网络往返加上线程切换,实际感知延迟可能到1ms甚至更高。减少RTT的关键是两个手段:连接复用和批量操作。连接复用靠连接池解决。连接池的核心参数包括最大连接数、最大空闲数、最小空闲数、连接最大空闲时间等。参数设置要考虑业务的并发峰值,而不是拍脑袋填一个数。比如业务峰值QPS是20000,单连接能支撑的QPS按5000算,最小也需要4个连接,还要留出40%的冗余,所以最大连接数在10个左右比较稳。批量操作靠Pipeline实现。Pipeline会把多条命令一次性发给Redis,再一次性收结果,能显著减少网络往返。注意Pipeline不是事务,它不保证原子性,所以只适合批量操作但不要求原子的场景,比如批量查询、批量设置。用Pipeline的时候还有一个细节:命令条数不宜过大,否则单次提交的数据包太大,反而增加网络延迟,建议按100~500条一批分批发送。5.4 本地缓存兜底:最后一层性能保险Redis再快,也快不过进程内的本地缓存。对某些极端热点的数据,可以考虑在应用本地再放一层缓存,比如用Map或本地缓存框架存最近访问的TopN热点数据。读取顺序变成:本地缓存 → Redis → 数据库。本地缓存能解决两个问题:一是大幅降低高频key对Redis的压力;二是在Redis抖动或短暂不可用时,应用还能继续对外服务,不至于瞬间全部回源数据库。但本地缓存也有明显的短板:多实例之间数据不同步。A实例更新了本地缓存,B实例可能还是旧值,所以本地缓存只适合对一致性要求不高、读多写很少的数据,而且TTL要设得非常短。我一般只在确认某个key是极高热点的场景才引入本地缓存,而且一定会配一个开关,方便出问题时随时降级回Redis直读。6. 这些配置没检查,上线迟早要出事:自检清单与观察点缓存设计得再漂亮,最后还是要回到上线后能不能稳定跑这件事上。我每次做完一个缓存项目,都会强制自己过一遍下面的清单,这也是我踩过几次坑之后总结出来的。6.1 上线前必须过一遍的清单检查项具体问题通过标准Key命名是否统一规范、便于排查按业务域前缀能快速筛选TTL策略是否有随机扰动、有没有永不过期的key不存在整点集体失效的风险空值/穿透处理非法ID、不存在ID是否走了兜底穿透率显著下降热key识别是否知道TopN热点key是哪些有明确的降级方案bigkey扫描是否存在超大value单key体积在可控范围连接池参数最大值是否覆盖峰值峰值时连接不被耗尽淘汰策略maxmemory和策略是否合理命中率符合预期监控告警命中率、延迟、内存是否接入告警关键指标有值班可感知这八项里,最容易临时抱佛脚的是bigkey和热key识别,建议上线前用现网流量做一次小范围灰度,把真实key分布拉出来看一眼,再决定要不要做拆Key或者本地缓存。6.2 上线后的监控指标与告警阈值上线不是终点,只盯着服务没挂远远不够。我给自己定的核心监控指标是四个:缓存命中率:命中率低于80%就要警惕,说明很多请求在回源数据库。当然不同业务的基准不同,但趋势性下滑通常意味着key设计出了问题。Redis慢查询:通过SLOWLOG查看执行时间超过阈值的命令。常见慢命令有大key的DEL、SORT、KEYS等,一旦出现就要立即优化。内存增长曲线:用INFO memory定期拉取used_memory,如果增长曲线不是阶梯状而是持续陡峭,基本可以判断有key没设TTL,或者value膨胀。活跃连接数:连接数接近连接池上限时,要留意是否出现了连接泄漏——很多Redis慢的问题,其实是应用层的连接等不到空闲连接导致的。告警阈值我建议分级:命中率连续5分钟低于阈值算Warning;慢查询数每分钟超过某个量算Warning;内存达到maxmemory的80%算Critical,要立刻处理。6.3 个人体会做Redis缓存设计和性能优化这么多年,我最大的体会是:缓存问题的表象千奇百怪,根源永远是没有在写代码前想清楚数据会怎么流动。穿透、击穿、雪崩、热key、bigkey,每一项都可以追溯到设计阶段的某个省略——省略了TTL扰动,省略了空值兜底,省略了key规范,省略了连接池参数验证。所以如果你现在正打算给业务上线Redis缓存,或者正在为一堆诡异的缓存问题头疼,回过头来把上面的决策挨个过一遍。一套靠谱的缓存方案,不是靠某个惊艳的技巧撑起来的,而是靠每一个基础选择都不犯大错堆出来的。先把地基打稳,性能优化才有意义。