★ FEATURED ARTICLE 刚开始接到这个任务我还挺头疼的。分布式缓存这四个字听起来太“教科书化”了网上随便一搜全是概念和架构图但真正从零开始动手实现过一套、并且把它推到线上扛住流量的人写出来的东西是完全不一样的味道。我这篇文章不是来复述“缓存是什么”的而是基于我最近从零搭建的一套分布式缓存系统把从技术选型、核心代码设计、高可用保障到线上故障排查的完整过程用踩坑的口吻记录下来。如果你正准备在自己的项目里落地分布式缓存或者已经在用了但经常遇到数据不一致、缓存雪崩、热点Key这些问题这篇文章应该能帮你少走不少弯路。1. 为什么偏要自己做一套Redis集群和分布式缓存层的真实边界很多人一听到分布式缓存第一反应就是“这不就是上Redis Cluster吗”。我在项目初期也是这么想的结果真把业务接进来之后才发现缓存这事远不止“把数据塞进Redis”这么简单。你需要的其实是两样东西一个是存储引擎也就是真的Redis节点另一个是你自己写的客户端封装层也就是决定数据怎么路由、怎么失效、怎么防雪崩的那一坨逻辑。这层东西官方客户端不会给你云服务商也不会给你。1.1 分布式缓存到底解决了什么本质问题在说实现之前我得先把“分布式”这三个字掰开揉碎。单机缓存比如进程里的LocalCache或者单点Redis面临的最核心瓶颈就是三个字资源上限。内存有限、连接数有限、单点吞吐有限。当你的业务QPS到了几万甚至几十万单机Redis的连接数可能先爆掉或者一次全量缓存重建直接打垮数据库。分布式缓存的本质不是把缓存“变大”而是把缓存的压力分摊到多台机器上同时让这个分摊过程对业务代码透明——调用方以为自己还在操作一个“大缓存”实际上背后是一组节点协同工作。这个“透明”是关键。如果你只是在客户端里写死几个Redis地址然后按用户ID取模分片那不叫分布式缓存那叫“手动分库分表”的缓存版因为你在做扩容、摘除节点、数据迁移的时候会痛不欲生。真正能被称为系统的分布式缓存至少得具备这几个能力数据分片Key按某种策略均匀分布到多个节点避免单点成为瓶颈。弹性伸缩增加或减少节点时数据迁移的影响面可控不会全盘重哈希。故障转移某个节点挂了请求能自动路由到其他节点或者降级而不是直接报错。高可用节点上的数据不能因为节点宕机就全丢需要有副本机制。治理能力慢查询、大Key、热点Key、命中率这些都得有办法观察。这些能力不是一个Redis Cluster全都能给你的。Redis Cluster确实提供了分片和主从故障转移但它的槽位迁移、倾斜检测、多Key操作的约束在实际业务里用起来很生硬。比如当你的单个Key访问量极高一个热点新闻的缓存KeyRedis Cluster只会把这个Key扔到其中一个槽里流量依然只有那一个节点在扛你还是得在客户端做额外的本地缓存来兜底。这就是我坚持要在客户端封装一层的原因——真正解决业务问题的逻辑往往藏在这一层里。1.2 第一版架构两层缓存与一组Redis集群的设计雏形我最终敲定的第一版架构不算激进主要分了三块应用内LocalCache层每个服务实例维护一份短TTL的本地缓存用来挡住最热点的那部分流量。Redis分布式缓存层使用一致性哈希分片的Redis集群解决容量和吞吐的横向扩展。DB兜底层缓存全部未命中时访问数据库并且通过互斥锁控制回源并发。这里要特别说一下LocalCache层。很多做后端的人对本地缓存是有偏见的觉得它在大规模集群下会导致每台机器的缓存不一致。但现实中热点数据的流量通常太猛了不加本地缓存的话Redis集群的压力降不下来。我见过最夸张的场景是几个热点账户的余额Key每秒请求上万次Redis节点的CPU直接被打到告警。加了本地缓存后这个数字直接降了两个数量级——代价只是极端情况下会出现最长几十毫秒的旧数据窗口。对这种业务来说完全可接受。2. 一致性哈希在工程里的真实面孔数据倾斜与虚拟节点的取舍如果这篇文章只能讲一个核心算法我一定选一致性哈希。它是分布式缓存的数据路由基石也是你从“把数据随机丢Redis”走向“让数据聪明地分布在节点里”的分水岭。2.1 一致性哈希环上最隐蔽的坑节点少时的hash环偏斜一致性哈希的标准思路是把每个节点映射到一个0到2^32-1的圆环上Key也哈希到环上然后顺时针找最近的节点存数据。这样做的好处是节点增减时只需要迁移相邻区域的数据而不是全部Key重新映射。但是理论到了工程里第一个坑就是节点数不够多的时候负载均衡根本做不到。我一开始只部署了3个Redis节点按一致性哈希跑起来之后测了下分布发现最忙的节点承受了差不多一半的请求另外两个节点闲得发慌。原因很好理解3个节点随机落在环上的位置是不均匀的如果它们挤在一坨那环上大半个圆弧范围的Key都被某个节点接管了。解决这个问题的标准手段是引入虚拟节点Virtual Node。每个物理节点在环上不只占一个位置而是占几百个甚至上千个位置范围是分散的。我试了不同数量级最终在项目里给每台物理节点分配了256个虚拟节点。效果立竿见影三个节点的负载分布从“一个忙死、两个看戏”变成了大家相对均匀地分摊。虚拟节点的实现不复杂核心思路是对每个物理节点生成一批带后缀的副本标识比如node-1-v1、node-1-v2这种然后对每个副本标识分别做哈希都放到环上。查找Key时先在环上找到虚拟节点再把它映射回真实节点。要注意的是虚拟节点存在内存里的代价很小但新增和删除节点时你要在内存结构里同步更新所有的虚拟节点位置这个操作如果是大集群会带来毫秒级的重建耗时——所以管理哈希环的数据结构得仔细选这个我后面讲。2.2 从一致性哈希到跳跃一致性哈希内存环的替代方案一致性哈希的环形结构虽然经典但它在两三百个节点以上的规模下有个尴尬的问题哈希环需要维护一份有序映射结构为了找Key要走二分查找而且重建环时要耗费O(n)的内存和CPU。在云原生环境下节点频繁弹性伸缩时这套东西太沉重了。后来我把路由算法换成了Google在2014年发表的Jump Consistent Hash。它的原理比环形哈希更优雅只需要给定Key和节点数量就能直接算出该Key落在哪个节点上。它没有“环”的概念内存占用是O(1)计算速度也很快。但Jump Consistent Hash有一个必须接受的限制它只支持节点的“末尾追加”和“末尾移除”不支持任意位置删节点。这意味着如果你要替换中间的一台机器你需要把它变成最后一台再操作。我在架构设计时给每个Redis节点做了编号后缀比如cache-01到cache-05就是为了换上新节点后能尽量往后追加避免中间删除带来的全量映射重算。如果你还在用老式的一致性哈希环建议评估一下节点规模规模小用环没问题规模大、变更频繁跳到Jump Consistent Hash会省很多心智负担。不过需要说明的是Jump Consistent Hash有“计算量随节点数增加而线性增长”的特性节点数到几千时性能会下降。对我这种几十个节点的场景完全无感。2.3 数据迁移的增量复制重哈希不是全量重来分布式缓存最让人头疼的操作就是扩容。用取模分片时扩容一台机器意味着几乎所有Key都要重新计算目标节点缓存瞬间变成一个巨大的空壳后面跟着的是一波数据库查询洪峰。一致性哈希的价值就在这里理论上只有一部分Key会被迁移。但在实际实现中迁移不能靠“读DB重建缓存”这种全量方式。我用的增量方案是给每个Key加一个版本号或时间戳后缀路由算法计算到某个Key对应的新老节点不同时老节点上的数据不立即删而是由后台迁移任务把它复制到新节点复制成功后短暂双写再由新节点接管流量。这本质上是一个“先迁移后切换”的过程能最大程度避免缓存穿透。这个方案我前前后后写了几十个小时里面有个细节差点让我崩溃——数据迁移的速度必须可控。如果不控制迁移速率Redis节点在RDB持久化时会因为内存和CPU被打满而失去响应。我最后给迁移任务做了动态限流对接了Redis实例的used_memory和info指标当节点内存占用超过70%就自动调慢迁移速度低于50%再恢复。这个经验是血泪教训换来的如果一开始就做好后面那场线上抖动的排查能省至少半天时间。3. 高并发冲击下缓存三大坑的实战防线穿透、击穿、雪崩在你真正把系统部署上去接受流量检验之前下面这三件事就是你能否站得住的大考。缓存穿透、缓存击穿、缓存雪崩这三兄弟是每个做分布式缓存的同学绕不过去的必修课。我在第一版上线后的第一次大流量活动里把它们挨个踩了一遍下面说下我最终落地的防护方案。3.1 缓存穿透布隆过滤器与空值缓存的组合拳缓存穿透说的是请求查询一个必然不存在的数据缓存里没有数据库里也没有于是每个请求都直接打到DB上。这个场景最典型的源头有两个一是恶意攻击者故意构造不存在的ID批量请求二是业务上确实存在高频查询“数据是否已删除”的场景。如果不防护DB的连接池几分钟内就会被耗尽。我的第一道防线是布隆过滤器。在内存里维护一个包含所有合法ID的布隆过滤器查询前先判断ID是否可能存在如果判断为不存在直接返回空结果根本不走缓存和DB。这里要注意布隆过滤器是有误判率的也就是说它可能把一个不存在的ID误判为存在但不可能把存在的ID漏掉。这个特性导致它只能拦截一部分穿透流量不能全拦。所以我又叠了一层空值缓存。当DB查出来是空数据时也把“这个ID对应的结果是空”写进缓存TTL设置得短一点比如60秒。这样就算布隆过滤器误判了也只会穿透到缓存层不会直接打到DB。两道防线叠在一起效果很好。我在压测时模拟了10万次无效ID请求加了过滤器和空值缓存之后真正打到DB的只有几百次。布隆过滤器的实现上要选择一个靠谱的内存结构我用的是Guava里的BloomFilter。要提醒的是布隆过滤器的大小和误判率强相关。我按100万条数据的量级预估设了千分之一的误判率最终占了大约200MB的堆内存。这个开销你得提前算好不然线上OOM你都不知道是谁干的。3.2 缓存击穿互斥锁回源与热点Key永不过期缓存击穿和穿透很容易混淆击穿指的是某个热点Key在失效的瞬间恰好有海量并发请求涌进来所有请求都发现缓存没有值于是全部扑向DB。区别在于穿透的Key本来就不存在击穿的Key是真实存在的热点数据只是在某段时间突然失效了。对付击穿最直接的手段是互斥锁回源。当缓存中查不到某个热点Key时服务不做即时回源而是先尝试获取一把关于这个Key的分布式锁只有拿到锁的线程或进程才允许去查询DB并回填缓存其他线程要么短暂阻塞要么直接返回一个托底值。我用Redisson实现的锁这个过程中最关键的是锁的过期时间必须比DB查询时间长很多否则DB慢查询还没执行完锁就过期了照样会击穿。但这套方案有个体验问题就是热点Key失效的瞬间部分请求会被阻塞RT会有一个尖刺。所以我一般还会叠加一个策略对真正的热点Key设置逻辑过期时间物理上不让它失效。怎么理解缓存里的Key的TTL设置成永不过期但存储的Value里带一个上一次更新的时间戳。后台有一个Cron任务定时扫描这些热点Key发现逻辑过期了就刷新一次。这种“逻辑过期配合异步刷新”的方案让我面对热点账本、秒杀商品这些场景时基本感觉不到缓存失效引起的抖动。3.3 缓存雪崩过期时间打散与多级容灾雪崩的性质比击穿更严重。它是大量Key在同一时间集体失效导致数据库在短时间内被巨量请求轰炸进而拖垮整个系统的连锁反应。最常见的触发原因是不规范的固定TTL设置——比如你给全部数据都设置了5分钟过期然后它们在同一时刻集体重生。解决雪崩的第一板斧是给每个Key的TTL加上随机偏移量。我在代码里统一封装了过期时间的生成方法实际TTL等于baseTTL random(0, 300)秒。这样就算同一天的数据集中写入它们的失效时间也会被均匀打散不会形成集体雪崩。第二板斧是多级容灾。即便缓存节点真的全挂了服务也不能直接瘫否则事故面会瞬间扩大。我在缓存客户端里做了多级降级链Redis不可用时先走LocalCacheLocalCache也没有时再尝试从DB查询并直接把结果返回同时打出一条告警日志。这样系统虽然响应变慢了但数据库不会被一次性打垮。这个方案的核心是治理必须前移——业务方在使用缓存时要清楚降级后的数据可能是旧的能不能接受由业务判断不能由缓存层替你做主。4. 缓存与数据库的一致性更新顺序、延时双删与订阅补偿缓存做久了你会慢慢意识到一个残酷的事实只要缓存和数据库是两套存储它们之间就不可能100%强一致。我们能做的是尽量缩短不一致的时间窗口并且在极端情况下有收敛机制。分布式缓存实现下来写一致性这一章的水最深也最考验架构能力。4.1 先更新DB再删缓存还是先删缓存再更新DB关于Cache Aside模式旁路缓存下写操作的顺序网上吵了很多年。我先说结论我之前踩过先删缓存再更新DB的坑——在并发环境下如果删除缓存后DB更新还没提交另一个请求把旧数据读回去并写进了缓存那么这个缓存会长期呈现旧值直到它过期。这是经典的“脏读并回填”问题。所以我最终采纳的是先更新DB再删除缓存的策略。这个顺序也有小概率出问题如果DB更新成功、缓存还没来得及删时一个请求读到了旧缓存并返回但一旦缓存删除成功后续请求就会强制从DB读取新值。不一致窗口极其短暂比先删缓存再更新DB的安全性高得多。需要注意删除缓存这一步不是同步地直接删就对了如果删操作失败会怎样所以我不会在业务代码里忽略删除失败的异常。删除操作会进入一个重试队列由后台任务确保删除最终成功。我把这个重试机制接到了项目自带的MQ上删除失败就发一条延迟消息5秒后再重试。4.2 延时双删看起来很美用起来要命网上广泛流传一个“延时双删”方案即在更新DB后立即删一次缓存然后隔几百毫秒再删一次。目的是把“并发读旧数据回填缓存”的窗口也干掉。我实验过后只能给出一个诚实的评价这个方案在低并发场景确实有效但在高并发下几乎失效。根本问题在于你第二次延时删除的“延时”到底该取多少完全取决于并发读请求回填的时间。并发越高、业务处理越慢这个时间越不稳定。你设了500毫秒结果一个慢请求在900毫秒后才回填旧数据第二次删除已经执行完了最终还是脏数据。所以在我最终的实现里没有纯依赖这种玄学手段而是靠下面这条更可靠的补偿链路。4.3 订阅Binlog一致性补偿一致性兜底方案如果要追求更可靠的一致性必须做到**“缓存删除失败也有兜底”**。我采用的是订阅数据库Binlog的方案。在项目里接入了Canal或者云厂商提供的Binlog订阅服务当数据库发生更新、删除时实时解析Binlog取出变更的主键然后主动删除对应的缓存Key。这套机制的好处是不管业务代码怎么写只要DB真的变更了就会有Binlog事件流出来缓存就有机会被动清理。实时性虽然比业务代码同步删缓存慢几毫秒到几十毫秒但胜在可靠。它做不了主路径但适合做收敛路径——主路径是业务代码里的同步删缓存收敛路径就是Binlog订阅兜底两者配合不一致的时间窗口被压到非常小而且不会出现永久性脏数据。这条经验我真的强烈建议所有做分布式缓存的人重视。数据一致性没有银弹关键是设计好主路径和兜底路径并且清楚它们各自的时间窗口和失效场景。5. 线上故障的完整排查链路一次“缓存慢查询”定位过程全记录这一节我想用一次真实发生的线上故障复盘来收尾因为分布式缓存的实现不是上线那一刻结束而是上线后第一次被流量揍的时候才刚刚开始。我记得有次大促流量高峰系统监控报警说某几个接口的P99延迟从80ms一路飙升到了3秒。我打开链路追踪平台第一眼看到是Redis的耗时异常增长直觉告诉我问题大概率出在缓存侧的某个环节。5.1 从客户端超时到Redis节点慢日志抓到大Key最初的排查方向是网络。我先看了服务器到Redis集群的TCP连接状态没有发现丢包重传网络监控也没异常。于是我把目光转向了Redis节点本身抓取了SLOWLOG结果在慢日志里发现有几个Key的GET命令耗时超过200毫秒。这个信号立即让我判断出这大概率是大Key(或热Key)问题——单体命令耗时长大都是因为Key对应的Value太大。让我说下大Key在Redis里为什么这么致命。Redis是单线程模型所有命令在同一个线程里排队执行当一个Value达到几MB甚至几十MB时这条GET命令在底层解压反序列化的时间会线性增长。这个增长是不可容忍的一个慢命令堵住整个节点后面的所有命令引起连锁的RT尖刺。更可怕的是我在压测时没注意这个Value的大小等到生产环境用户的复杂数据结构把Value撑到几MB时问题才全面爆发。5.2 用DUMP与内存分析确认热点Key的分布确认大Key只是第一步我需要知道这些大Key到底长什么样子、分布在哪里。我用redis-cli --bigkeys做了一次扫描分析发现占用内存排前面的几个Key全部是某类业务实体的完整JSON字符串单个Value最大到了4.8MB。这其实暴露的是设计问题把整个实体大而全地塞进缓存虽然开发省事却是缓存系统的头号隐患。我最终的解法是分层拆缓存把大实体拆成概要信息和高频字段两部分概要部分TTL长完整详情走单独的Key且在数据变更时按字段级更新。处理后单Key的最大Value从4.8MB降到了不到30KBRedis节点的平均RT直接降了一个数量级。这个操作让后面的接口性能直接从秒级恢复到了几十毫秒效果极其明显。如果你正在排查自己的缓存系统我强烈建议你提前在压测环境注入一些大Value场景别等线上卡了才想起来查。顺便提一句GC的STWStop The World问题也会引起Redis耗时增长但那是另一个维度的排查路径如果你发现Redis节点CPU不高但频繁有100-200ms的尖刺建议先检查一下系统内存分配策略再怀疑大Key。5.3 恢复现场的策略选择局部清理优先于全量清空当一个大Key把Redis节点堵死你第一个念头可能是“把所有缓存都清掉不就好了”。但这个操作恰恰是最危险的——全量清空缓存会让所有请求瞬间打到数据库这会在缓存雪崩之上再叠加一次更猛烈的击穿。我会建议按“最小牺牲”原则恢复优先剔除大Key用UNLINK命令而非DEL。按业务维度逐步摘除缓存让流量先降级到DB再从DB逐步回填缓存。禁止全量FlushDB一定保留一个应急开关来限制回源的并发量。我当时是用脚本批量找出大Key并逐个UNLINK成批删除的。这里要注意DEL和UNLINK的区别DEL是同步删除在Value极大时会阻塞主线程UNLINK把删除操作交给后台异步线程主线程不会被阻塞。当时我们差点就用DEL把事故加码了幸好及时发现了这个细节。6. 可观测性与压测验证缓存系统上线前必须做满的功课一个分布式缓存系统实现完了在交付团队使用和上线前有两件事一定要做扎实可观测性建设和压测验证。没有这两项你根本无法在线上快速定位问题。甚至可以说这两项工作才是整个系统能稳定运行的前提。6.1 缓存系统必须埋的三类指标缓存侧的监控指标不能只看Redis实例的存活状态要围绕这三个维度埋点命中率维度总的查询命中率、各业务维度的命中率。命中率下滑往往是缓存被误清或者Key设置不合理的信号。耗时维度缓存客户端的GET/SET平均耗时、P99耗时、慢请求数。发现耗时上涨结合大Key扫描和节点慢日志定位。一致性维度缓存删除失败的队列积压数量、延迟双删的失败率、订阅Binlog补偿的处理延迟。这些指标直接决定你数据最终一致性的健康度。这些东西我全部接到了统一监控大盘上。遇到过最有价值的一次是我通过命中率维度的分钟级曲线发现一个业务在固定时间点命中率骤降顺着查下去发现是某条定时任务有Bug会把一个前缀的所有Key批量删除因为缓存Key明明还在却都失效了。如果没有监控这种隐性Bug可能要过很久才能被发现。6.2 压测出来的瓶颈才叫瓶颈开发完缓存系统后我做了一轮专门针对缓存的压测。压测不是简单地把QPS打上去就行而是要有目的地测这几个场景热点Key集中访问模拟单个Key每秒几万次访问观察Redis节点CPU和本地缓存层的拦截效果。Key批量失效模拟一批Key同时过期观察回源并发和数据库连接池水位。节点宕机切换手动kill一个Redis主节点观察客户端重连、从节点晋升和故障期间的请求耗时。在这一轮压测里我发现了一个很隐蔽的问题当Redis主节点宕机之后客户端实现的故障转移逻辑能工作但是因为初始化Jedis连接池时设置的是固定数量的连接切换到了新主节点后出现了连接数不够用的情况。后来我调整成了弹性扩缩容的连接池配置并在压测里把新主节点的容量也纳入容量规划。这些藏在细节里的坑只有真实的压测才会暴露。6.3 上线前Checklist每个想用分布式缓存的项目都应自检最后附上一个我每次上线前都会过一遍的清单。这几个问题你用脑子过一遍比执行多少条命令都有用有没有统一封装缓存客户端而不是让业务直接new一个Redis实例到处用Key是否规范带上了业务前缀是否规划好了命名空间和过期时间策略热点Key的本地缓存兜底做了没有互斥锁回源带了没有缓存删除失败后有没有进入重试队列或订阅Binlog兜底压测环节里有没有模拟节点宕机、大Key、热Key这些极端情况监控大盘里有没有命中率、耗时、一致性三个维度的指标告警这些问题如果一个没有准备好就想上线你自己会变成整个团队里第一个收到深夜报警电话的人。我自己当初就是因为没提前做热Key演练上线后被人群流量打懵过现在每次新系统上线前这套问题都要被我反复问一遍。这一整套做下来之后我对分布式缓存的理解也从“用Redis存数据”变成了“设计一套有路由、有治理、有兜底、有监控的缓存基础设施”。每个环节的取舍背后都是线上场景逼着做的决定没有一步是可以靠想当然糊弄过去的。希望这篇实现记录能帮你从“会用Redis”进化到“能搭一套扛得住事的分布式缓存系统”。
阅读完成 · 觉得有帮助？
