1. 饿了么CPS系统的业务命门每一个点击都要算清楚钱很多做Java后端的朋友一听到CPS就下意识觉得这不就是个返佣系统嘛用户点链接、下单、然后按比例分钱有什么好设计的。但真正把饿了么这类本地生活CPS系统跑起来之后你会发现它跟传统的电商CPS有本质区别——外卖场景下的用户决策链路极短流量突刺极猛而且每一笔佣金归属都不能错。我最早接手这块业务的时候第一周就被线上告警打懵了。中午11点到13点这个时段某个头部渠道推广的“超级吃货红包”链接一旦放量同一个商品详情页的QPS能瞬间冲到几万而这些请求里绝大多数的数据——商品信息、店铺信息、红包面额、佣金比例——都是同一个key里的同一份数据。数据库根本扛不住这种读放大Oracle扛不动MySQL也扛不动唯一的出路就是把热点数据往Redis里放。但放进去只是第一步真正麻烦的是后面这些事怎么保证缓存里的券包信息跟商家后台实时一致怎么防止一个key被打挂导致整个集群雪崩佣金比例这种敏感数据能不能直接走Cache Aside这些问题不解决缓存上了也是饮鸩止渴。这篇文章我就结合自己实际维护饿了么CPS系统的经验把Java操作Redis做热点数据缓存的完整设计思路拆开讲。不讲那种面试用的八股定义全部是线上验证过的方案、代码和踩坑记录。适合已经会用Redis基本命令、但正在头疼高并发场景下缓存设计的Java开发同学参考。1.1 CPS闭环里的每一步都在跟Redis打交道先画一下饿了么CPS的业务闭环这样后面讲方案你才有画面感。用户从某个渠道比如外卖优惠券公众号、社群分享、短视频挂载链接看到一个带推广标识的饿了么链接点击之后会经过一个统一转链服务生成带channel标记的落地页。这个过程要做几件事把渠道标识解析出来、校验推广位合法性、给用户生成一个跟踪用的会话标识。然后用户领券、下单、支付、出餐、完成订单订单结束后系统要根据整个链路上的归属关系计算佣金。这里面每一步都是典型的读多写少场景渠道配置信息一写多读基本不变但每次转链都要读。商品/店铺详情商家后台改了价格或库存后要同步用户端读取频次极高。券包活动配置活动上线时写入活动周期内被海量用户读取。用户跟单关系下单时要快速判断这个用户是不是某个渠道带来的这直接决定佣金归谁。这些数据的共同特点是读QPS远大于写QPS但一旦写发生比如商家改价读方需要快速感知。Redis恰好就是这个场景的标准答案。但如果你真的只用一个String类型、裸调set/get、然后把序列化方式随便配一下那基本等于给自己埋雷。1.2 缓存设计必须从业务特征反推我做技术方案有个习惯先不看代码先问业务三个问题这份数据多大多热多重要对应到CPS场景就是第一问多大商品详情包含名称、图片、分类、价格、起送价、配送费、评分等十几个字段一个商品序列化后大概1KB到3KB。券包信息小一些几百字节。店铺信息最大可能带营业时间、公告、门店列表能到5KB以上。第二问多热外卖有明显的时段效应11:00-13:00和17:00-19:00是绝对高峰。更麻烦的是热点呈现“脉冲式”一个公众号推文发出去五分钟后某个商品的访问量能从几百跳到几十万。第三问多重要商品价格和佣金比例错了要么用户下单后纠纷要么渠道方结算时扯皮。这类数据不能像普通session一样丢了就丢了必须有一致性保障。这三个问题的答案决定了我的缓存设计不是简单的“KV塞进去”而是要分层次、分场景、分优先级去做。2. 数据结构选型CPS场景下String、Hash、ZSet到底怎么排兵布阵网上聊Redis数据类型的文章多如牛毛但大多停留在“String存字符串、Hash存对象”这种层面。真到了CPS这种混合读写、部分字段频繁更新的场景选错结构直接让你的内存和CPU双双爆炸。2.1 商品与券包详情Hash比String更适合字段级更新先说结论商品信息、券包信息这类“一个key对应多个字段、且部分字段会单独更新”的数据我建议优先用Hash。举个具体例子。饿了么商家在后台改价格你的服务收到变更消息后需要同步更新Redis里的缓存。如果用String存整个商品JSON你要先get出来、反序列化成Java对象、改字段、再序列化、再set回去。这看起来没啥问题但高并发下两个线程同时改不同字段就会发生互相覆盖——专业点说叫“更新丢失”。比如运营改了满减标签另一个线程改了配送费后写的那次覆盖会把先写的改动丢掉。用Hash就清爽得多HashOperationsString, String, Object hashOps stringRedisTemplate.opsForHash(); hashOps.put(cps:product:detail: productId, price, newPrice); hashOps.put(cps:product:detail: productId, deliveryFee, newFee);只更新需要的field互不干扰。同时Hash在内存布局上对小对象有压缩优化ziplist/hashtable转换比存整串JSON更省内存。但是注意Hash不是银弹。如果你的value是整体替换的——比如整个详情页模板都变了旧结构已经没有复用价值——那Hash的更新反而麻烦你得delete再重新putAll。所以在CPS项目里我一般这么分商品基本信息字段多、部分更新频繁→ Hash转链token生成后整体读取、验证后即焚 → String店铺评分、销量榜分值增减 → ZSet领券用户去重防止一个用户重复领同一个券包 → Set2.2 会话跟踪与幂等标记String 过期时间是王道CPS转链后生成的用户会话标识本质上是一段“临时凭证”。它有两个要求一是读取速度快二是必须有过期时间。String配合Redis原生expire就是最合适的组合别去用Hash给会话加了一堆字段白白增加内存和序列化开销。幂等标记也一样。用户领券请求为了防止重复提交用一个setNx命令就能搞定Boolean first stringRedisTemplate.opsForValue() .setIfAbsent(cps:coupon:req: userId : couponId, 1, Duration.ofSeconds(30)); if (Boolean.TRUE.equals(first)) { // 处理领券逻辑 }这个操作就是Redis分布式锁以及各种幂等控制的底层原语在CPS系统里大量使用因为它同时满足了原子性和自动过期两个需求写一行抵得上Java里synchronized 定时清理一堆代码。2.3 佣金榜单与排序场景ZSet的独特价值CPS业务里有个运营很喜欢的功能——实时榜单哪个渠道带来的订单最多、哪个商品推广转化最高。这个需求如果用数据库做ORDER BY在千万级流量下就是灾难如果纯Java内存做集群多节点又没法共享。Redis的ZSet天生就是干这个的zSetOps.incrementScore(cps:rank:channel:today, channelId, 1);每次有效订单回调时给对应渠道加一分运营页面直接reverseRangeWithScores取TopN。复杂度低、实时性高、还能顺便做小时级/天级滚动排行——用一个zUnionStore或者约定key后缀加时间窗口就行。2.4 序列化方案里的两个深坑说完了结构必须重点说序列化。这是Java操Redis最容易翻车的地方没有之一。第一坑用JdkSerializationRedisSerializer存对象。Spring Boot 1.x的老项目很多默认用这个序列化后是一坨带类结构信息的二进制肉眼不可读不说 最大的问题是一旦你改了实体类的包名、类名或字段名反序列化直接抛异常线上会遇到批量缓存失效。而且它体积很大一个几百字节的JSON能被撑到两三KB内存吃紧。第二坑用GenericJackson2JsonRedisSerializer把对象带类型信息一起存但类删了字段。JSON反序列化默认遇到未知字段会报错虽然可以配置FAIL_ON_UNKNOWN_PROPERTIESfalse但团队协作中特别容易漏配。更隐蔽的是如果实体类里有个字段从String改成了Integer旧缓存里的JSON字符串还在反序列化时类型转换异常会让你排查到头秃。我的实践是缓存里存纯业务JSON字符串用StringRedisTemplate直接读写代码里手动做对象的序列化和反序列化。虽然每次要多写一行业务代码但换来的是缓存结构完全可控、可排查、可兼容。// 手动序列化写入 ProductCache product buildProductCache(productDO); stringRedisTemplate.opsForValue().set( buildProductKey(product.getId()), JSON.toJSONString(product), 30, TimeUnit.MINUTES ); // 手动反序列化读取 String cached stringRedisTemplate.opsForValue().get(buildProductKey(id)); if (StringUtils.hasText(cached)) { return JSON.parseObject(cached, ProductCache.class); }配套的类里所有字段都要考虑兼容性。我习惯在缓存实体里不直接使用业务DO而是单独建一个xxxCache类字段精简、状态清晰、预留一个version字段后续做缓存结构升级时能通过版本号做渐进迁移而不是一把梭全部删了重建。3. 热点Key治理实录从一场“爆品突刺”说起缓存设计好之后真正的战斗在于线上流量的不确定性。我印象最深的一次事故是一个美食博主在短视频里挂了一个“5元吃外卖”的饿了么CPS链接视频发出去三分钟我们后台监控看到某个券包的访问QPS从800直接飙到4万而且全部集中在同一个Redis key上。这个场景就是典型的**热点KeyHotKey**问题高频访问集中在极少数key上单个分片CPU打满其他分片闲置整个集群的吞吐被这一个key拖垮。如果不干预紧接着就是这个分片的网络带宽打满、其他业务读写也开始排队最终“单点故障”引发“集群雪崩”。3.1 如何尽早识别热key而不是等告警来找你热key的发现分三层来搞每一层的成本和效果都不一样。第一层Redis原生能力。如果你用的是Redis 4.0以上可以执行redis-cli --hotkeys如果用的是云Redis控制台一般有“热key分析”功能可以定时拉取。这个方法最大的问题是它只能事后看而且扫描本身有额外开销生产环境不能频繁跑。第二层代理层/客户端侧统计。我们项目的Java服务用的是Lettuce连接改造它做请求染色门槛有点高但可以通过包装RedisTemplate对get和hGetAll等高频方法做本地滑动窗口计数。实现很简单public class HotKeyCounter { private final LoadingCacheString, Long counter CacheBuilder.newBuilder() .expireAfterWrite(10, TimeUnit.SECONDS) .build(new CacheLoaderString, Long() { public Long load(String key) { return 0L; } }); public void increment(String key) { counter.asMap().merge(key, 1L, Long::sum); } public MapString, Long snapshot() { return Maps.newHashMap(counter.asMap()); } }每次Redis操作前counter.increment(sanitizeKey(rawKey))然后定期比如每10秒把计数超过阈值的key上报到监控系统或告警平台。用Caffeine或者Guava的Cache做本地窗口计数开销可以忽略不计。第三层业务预判。比上面两层都更前置的是在业务代码里主动标记“这个key可能爆”。比如CPS转链服务里渠道方会提前告诉你“我们明天中午推一波量”那就直接把相关key的访问路径改成走本地缓存副本。3.2 热key拆分的通用模式key加后缀 轮询热key一旦被确认最粗暴也最有效的方案就是把一个key拆成多个副本让请求分散到不同分片。具体做法是这样的。原keycps:product:detail:10086被打爆我们把它拆成cps:product:detail:10086:0到cps:product:detail:10086:9十个副本每个副本的数据完全一致。读取的时候对请求做取模轮询private static final int HOT_KEY_BUCKET_SIZE 10; private String buildHotKey(Long productId, int bucket) { return cps:product:detail: productId :hot bucket; } // 读取时随机或按请求特征落到某个副本 private String readProductFromHotCache(Long productId, int hashSeed) { int bucket Math.floorMod(hashSeed, HOT_KEY_BUCKET_SIZE); return stringRedisTemplate.opsForValue().get(buildHotKey(productId, bucket)); }每次写缓存时要写全这十个副本。初看会觉得存储浪费了十倍但仔细想想热点数据本身占比极小十个副本也就几十KB到几MB换来的是单key QPS的打散非常划算。如果你用的是Redis Clusterkey加了后缀还会自动分布到不同分片连分片的热点都一并解决了。3.3 本地缓存兜底Caffeine怎么配才不出事热key拆分的尽头还有一个终极大招——本地缓存JVM内缓存。Redis再快也是网络IO本地缓存是纯内存读取耗时从毫秒降到微秒级别。CPS场景里对已经被标记为高热的商品详情我习惯加一层Caffeine本地缓存。配置上有个关键点Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(Duration.ofSeconds(15)) .build(key - loadFromRedis(key));过期时间不能太长我压测过很多组参数15到30秒是性价比最高的区间。太短了比如5秒本地缓存命中率上不去每次过期后瞬间的回源请求还是会打到Redis太长了比如5分钟又会导致商家改价后用户侧长时间看到旧数据投诉就来了。本地缓存的高危点是内存和GC。maximumSize要设为有上限的千万不能无界缓存。我见过一个项目为了追求性能把maximumSize设为Long.MAX_VALUE结果大促期间缓存了上百万个商品详情堆内存被打爆FGC频繁反而把服务拖死了。设了maximumSize之外最好再结合recordStats()监控命中率低于阈值就实时告警及时排查key为什么分散。4. 穿透、击穿、雪崩三兄弟在CPS里各有各的马甲如果你搜过Redis缓存相关的内容穿透、击穿、雪崩这“三兄弟”几乎是必聊话题。但网上98%的讲解都在背定义到CPS的真实场景里到底怎么处理很多文章压根没提。我只讲实操。4.1 穿透CPS的恶意刷量和参数校验到底怎么筛缓存穿透的根因是查询了一个缓存和数据库里都不存在的数据。在CPS系统里最常见的穿透来源有两个一是外部渠道方用脚本随机生成商品ID批量刷接口企图薅平台反作弊的羊毛二是用户访问了一个已经下架或未上线的活动页面参数永远解析不到。对付穿透业界标准方案是布隆过滤器Bloom Filter。我在这套系统里做得比较轻量在服务启动时把当天所有有效商品ID和活动ID全量加载到布隆过滤器里或者用一个前缀标识查询前先过滤一遍如果布隆过滤器判断不存在直接返回空结果压根不碰Redis和数据库。public class BloomFilterService { private final BloomFilterString productFilter; public BloomFilterService(ListLong onlineProductIds) { productFilter BloomFilter.create( Funnels.stringFunnel(StandardCharsets.UTF_8), onlineProductIds.size(), 0.01 // 允许1%的误判率换内存空间 ); onlineProductIds.forEach(id - productFilter.put(product: id)); } public boolean mightContain(String key) { return productFilter.mightContain(key); } }注意布隆过滤器是“宁可错杀一千不可放过一个”的反向过滤器——它说“不存在”就一定不存在它说“存在”则可能误判。所以误判率要设置合理1%左右既能控制内存占用又不会因为误判把大量无效请求放进数据库。这个方案不用引入额外的中间件Guava的BloomFilter足够用。4.2 击穿热点券包过期那一瞬间的系统崩溃缓存击穿指的是一个热点key在过期的瞬间大量请求同时穿透到数据库。结合前面那个“5元吃外卖”案例如果那个券包配置的缓存过期时间到了而此时又有几万人在同时请求那对数据库的压力就是灭顶之灾。网上的标准答案是“互斥锁重建缓存”用Redis的setNx做一个分布式锁让只有一个线程去查库重建缓存其他线程等待锁释放后直接读新建好的缓存。这个思路对但实现有讲究public ProductCache queryProductWithMutex(Long productId) { String cacheKey buildProductKey(productId); String cached stringRedisTemplate.opsForValue().get(cacheKey); if (StringUtils.hasText(cached)) { return JSON.parseObject(cached, ProductCache.class); } String lockKey lock:product: productId; Boolean locked stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, 1, Duration.ofSeconds(5)); if (Boolean.TRUE.equals(locked)) { try { // 二次查缓存防止上一个线程已经重建好了 cached stringRedisTemplate.opsForValue().get(cacheKey); if (StringUtils.hasText(cached)) { return JSON.parseObject(cached, ProductCache.class); } ProductCache product loadFromDatabase(productId); stringRedisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(product), 300, TimeUnit.SECONDS); return product; } finally { stringRedisTemplate.delete(lockKey); } } else { // 没有抢到锁的线程短暂自旋后读缓存 Thread.sleep(50); cached stringRedisTemplate.opsForValue().get(cacheKey); if (StringUtils.hasText(cached)) { return JSON.parseObject(cached, ProductCache.class); } return queryProductWithMutex(productId); // 递归重试必须加超时控制 } }有几个细节要说清楚抢到锁后必须二次查缓存否则两个线程同时抢锁、第一个线程还没释放、第二个线程等锁期间第一个线程已经把缓存写好了第二个线程再去查库就是白费。锁要有过期时间防止线程持锁后崩溃导致死锁。5秒是个经验值需要保证重建缓存的操作能在5秒内完成如果业务逻辑重要适当调大。等锁的线程用Thread.sleep(50)自旋这里的自旋次数和总超时要控制最简单的方式是在递归入口传入一个tryCount超过10次就放弃锁等待直接查库并返回宁可数据库压力大一点也不能把用户请求无限阻塞下去。4.3 雪崩过期时间别整整齐齐缓存雪崩的经典定义是大面积key同时失效。在CPS场景里最常见的触发点是整点活动批量上架。比如某个渠道方一次性配置了1000个券包每个券包的缓存过期时间都被设成了整点后30分钟那到了这个时刻一千个key同时过期Redis重建缓存的线程瞬间打满数据库直接被压垮。破解方法很直白过期时间加随机偏移。int baseExpireSeconds 30 * 60; int randomExtra ThreadLocalRandom.current().nextInt(300); // 0~5分钟随机偏移 cacheKeyOperations.set(key, value, Duration.ofSeconds(baseExpireSeconds randomExtra));从300秒的随机偏移开始根据活动规模调整。大促时期我习惯把偏移加到600秒让过期时刻均匀散落在10分钟的时间窗里。另一个容易忽略的雪崩点是批量预热。活动上线前运营配置好了1000个券包你以为写个for循环把数据都set进Redis就完事了结果这1000次set全部瞬时完成、又全部在同一时间过期问题依旧。正确的预热策略是把预热请求也打上随机延迟让数据在活动开始前的几分钟内陆续写入过期时间自然就错开了。5. 佣金数据的一致性问题缓存和数据库谁说谎前面讲的都是“缓存怎么扛流量”但CPS系统里最容易被忽略、也最容易出大事的其实是数据一致性。尤其是佣金比例、渠道结算价这类数据一旦缓存里的值和数据库不一致轻则渠道方投诉重则直接产生资损。5.1 CPSS结算场景下为什么不能无脑Cache AsideCache Aside模式先更新数据库再删除缓存在大多数业务场景下是效率与一致性之间的最优解。但CPS场景里有个特殊点佣金数据变更的窗口期正好是流量高峰期。比如商家后台晚上八点调整了佣金比例而这个时间点刚好是外卖订单发布高峰如果按“更新数据库后删缓存”的套路走删缓存后的一瞬间有大量请求发现缓存为空会同时回源数据库去重建缓存——也就是击穿。更麻烦的是数据库更新成功但删除缓存失败Redis短暂不可用那缓存里就一直留存旧佣金比例用户在该渠道下的订单全部按旧比例结算渠道方就会不满意。所以对于佣金数据我的原则是能不用缓存就不用缓存必须用缓存就必须接受短暂不一致但绝不让不一致持续超过一个可接受的窗口比如1分钟。做法是给这类数据设置很短的过期时间比如60秒配合主动刷新让缓存数据变成“准实时副本”而不是试图去追求完全的强一致。5.2 延迟双删 版本号的工程实践对于商品详情这类需要快速感知商家改价的数据我最终采用的组合方案是延迟双删 版本号。延迟双删的流程是更新数据库后先删除缓存等待一小段时间几百毫秒级别再次删除缓存。第二次删除解决的是并发场景下的旧数据“回写”问题——线程A读到了旧数据准备写缓存线程B更新了数据库并删了一次缓存线程A随后把旧数据写回了缓存此时第二次删除就能把这个脏数据清掉。但“等待一小段时间”这个设计非常尴尬等待时间太短线程A还没完成写缓存动作第二次删除就白删了等待时间太长用户读到旧数据的窗口就变大了。我调试了很久最终用的等待时间是500ms因为我们的缓存序列化和写入耗时实测在50ms以内500ms足够覆盖99%的写回延迟。除了延迟双删我在缓存实体里强制加了一个version字段。举个场景用户读了一次商品详情缓存本地存的是version3商家运营改价后数据库版本变成了version4服务端尝试用version3的旧数据去回写缓存时因为Redis里的版本已经不匹配写不进去。具体用Lua脚本实现这个“比较并写”的原子操作if redis.call(HGET, KEYS[1], version) ARGV[1] then return redis.call(HMSET, KEYS[1], unpack(ARGV, 2)) end return 0这套“双删兜底 版本兜底”的方案上线后线上没有出现过一次商家改价后用户长期看到旧价的事故。对比一下删缓存能解决大多数场景而版本号和Lua能保证即使删除失败也有最后一道防线拦住脏数据。5.3 实际踩过的坑第二次删除失败竟是因为管道复用延迟双删上线一个月后我们遇到一个诡异现场偶发出现用户看到旧价格排查发现第二次删除根本没执行。日志里delete返回了true但缓存竟然还在。后来定位到原因是Redis连接池里的连接被应用提前归还。当时用的连接池配置了maxTotal和maxIdle但代码里在try-with-resources块之外调用了returnObject导致连接在异步写回的过程中被复用第二次删除请求和旧数据的写回请求走了同一条连接、产生了竞态。修掉这个连接管理问题后双重删除才算真正稳定。这里给一个排查建议如果你的缓存系统出现“明明删了却还有旧数据”的灵异事件第一反应别去怀疑Redis命令先看客户端连接池的归还时机和复用策略。Java的Lettuce和Jedis在高并发下都有可能因为连接复用引起请求错乱这是非常隐蔽的坑。6. 大促前的体检热点缓存系统的治理清单方案讲完了最后分享一套我每次大促前必做的Redis缓存体检清单也算是给这段经验一个可落地的总结。不要等流量到了才手忙脚乱提前做这五件事6.1 第一件事验证过期时间分布写一个脚本把Redis里所有cps:前缀的key的TTL拉出来按过期时间画个分布图。如果发现大量key在同一个时间窗口内过期立刻加随机偏移修复。这个检查对CPS系统尤其重要因为活动配置的过期时间天然容易聚簇。6.2 第二件事压测本地缓存命中率模拟大促峰值流量压测本地缓存Caffeine的组合观察命中率是否在95%以上。如果命中率偏低检查热key拆分是否生效、过期时间是否设置过短。我见过的最常见问题是代码里用了Cacheable注解缓存了完整的ProductDO对象但key里包含了用户维度比如用户ID导致同一个商品被几百个用户各自缓存了一份命中率上不去内存也白白消耗。CPS这类场景的缓存key一定要以商品/券包/渠道这种业务实体为单位绝不能掺入用户维度。6.3 第三件事数据库连接池水位检查缓存击穿时最后一道防线是数据库。大促前必须确认数据库连接池配置能否扛住“瞬间全量回源”的最坏情况。我一般把连接池最大连接数压到比平时多2到3倍同时配好等待队列宁可请求排队等待也不能把连接池打崩导致数据库假死。6.4 第四件事Redis内存与分片均衡用redis-cli --bigkeys或云控制台检查是否有大key观察集群各分片的内存使用是否均衡。热key拆分的期限就是要均匀分布到各分片如果发现某个分片CPU明显高于其他分片就说明热点key的拆分粒度还不够。6.5 第五件事演练故障恢复最后找一个流量低峰期人为干掉一个Redis分片或让某个热key失效观察Java服务的行为。重点验证三件事服务能不能自动重连其他分片、本地缓存能不能扛住回源压力、告警能不能及时发出。这套演练我用过很多次每次都至少能找出一个“想当然没测过”的盲区——比如某次演练发现一个老服务用了Autowired注入RedisTemplate但连接工厂没有配重试策略分片挂了之后整个请求直接报错完全没有降级逻辑。做CPS系统这几年我最大的体会是热点缓存设计从来不是“把数据放进Redis”这么简单它是一整套流量治理的工程体系。从数据结构选型、序列化方案、热key拆分到穿透击穿雪崩的防御、最终的数据一致性兜底每一层都不能偷懒。特别是Java这种强类型语言序列化和版本兼容的坑远比想象中多宁可前期多花时间设计也别等线上资损了再来复盘。如果你现在正好在做类似的电商/本地生活CPS项目建议先把文中的方案按照自己业务的流量特征做一轮适配重点去看热key拆分和本地缓存兜底这两块。这两块是投入产出比最高的也是最能在关键时刻救命的。