1. 缓存技术选型的本质思考第一次被问到为什么用分布式缓存时我正坐在美团西二旗办公室的会议室里。面试官的手指在MacBook Pro上轻轻敲击这个看似简单的问题背后实际上在考察我们对系统架构本质的理解。本地缓存就像你办公桌抽屉里的常用文件伸手就能拿到。而分布式缓存更像是公司共用的文件柜所有部门的人都能存取。当你的应用只有单个实例时用本地缓存确实就够了就像小团队共用一个办公室时抽屉就能满足需求。但美团这样的平台高峰期要处理数十万QPS的订单请求就像一个有上万员工的集团公司这时候就必须建立完善的共享存储体系。我见过不少初级开发者犯的典型错误——在微服务架构中滥用本地缓存。比如去年排查的一个优惠券系统故障就因为各个节点本地缓存不一致导致同一用户在不同服务节点看到不同的优惠券状态。这就像分公司各自维护客户资料却不及时同步必然会出现信息混乱。2. 分布式缓存的核心价值2.1 数据一致性保障分布式缓存最核心的价值在于提供了单一数据源Single Source of Truth。我们用Redis集群时所有服务节点读取的都是同一份数据。这就像集团公司使用统一的ERP系统任何部门看到的客户信息都是实时一致的。在美团外卖的业务场景中商家库存就是个典型例子。假设某餐厅最后一份黄焖鸡如果使用本地缓存用户A在节点1看到有库存并下单用户B在节点2也看到有库存并下单 这就出现了超卖。而用Redis集群存储实时库存所有请求都通过SETNX原子操作扣减就能避免这个问题。2.2 高可用与扩展性Memcached/Redis集群可以做到99.99%的可用性通过主从复制和哨兵机制实现故障自动转移。这就像大公司的文件柜有备用电源和灾备系统比个人抽屉可靠得多。当业务量增长时只需要水平扩展Redis集群节点即可。去年双十一前我们通过增加Redis分片将缓存吞吐量从5万QPS提升到20万QPS整个过程对业务无感知。而本地缓存受限于JVM内存扩展需要重启应用在美团这种体量的业务中根本不可行。3. 本地缓存的合理使用场景3.1 适合使用本地缓存的三种情况静态配置数据比如城市行政区划这类极少变更的数据。我们用一个PostConstruct加载到ConcurrentHashMap访问速度比Redis快10倍以上。防穿透保护在查询分布式缓存前先查本地缓存。我们实现了个二级缓存装饰器对不存在的商品ID缓存5秒空值去年618期间减少了30%的缓存穿透请求。高频只读数据用户基础信息这类变更频率低但读取量大的数据。我们在网关层用Caffeine缓存命中率能达到85%大幅降低下游压力。3.2 性能对比实测数据通过JMH基准测试测试环境4C8G云主机缓存类型平均耗时QPS上限内存占用HashMap28ns2000万受限于堆内存Caffeine45ns1500万可设置上限Redis1.2ms8万可扩展可以看到本地缓存的性能有数量级优势但需要接受数据不一致的风险。4. 多级缓存一致性方案4.1 美团现网采用的架构我们的多级缓存体系分为三层客户端缓存APP内缓存静态数据通过版本号控制更新网关缓存Nginx Lua实现边缘缓存TTL 1-5秒服务端缓存Redis集群 本地Caffeine4.2 一致性保障的五个关键措施失效广播机制通过Kafka发送缓存失效事件所有节点订阅处理。比如修改商品价格后会广播如下消息{ eventId: cache_evict, key: product:12345, timestamp: 1630000000 }版本号控制所有缓存数据带版本号客户端请求时必须携带本地版本。我们在HTTP头中添加X-Cache-Version: 1630000000延迟双删策略写操作时先删缓存再更新DB最后延迟500ms再删一次。代码示例public void updateProduct(Product product) { // 第一次删除 redis.del(product:product.getId()); // 更新数据库 db.update(product); // 提交延迟任务 delayQueue.add(() - { redis.del(product:product.getId()); }, 500); }binlog监听通过Canal监听MySQL binlog实时感知数据变更。我们维护了商品ID到缓存键的映射关系表当监听到update操作时自动触发缓存更新。熔断降级策略当Redis集群异常时自动降级到本地缓存并在控制台醒目告警。我们基于Hystrix实现HystrixCommand(fallbackMethod getFromLocalCache) public Product getProduct(long id) { // 正常查询Redis逻辑 }5. 典型问题排查实录5.1 缓存雪崩事故复盘去年双十一零点某品类商品缓存集中失效导致DB瞬时QPS飙升到15万。我们的处理步骤立即在运维平台执行redis-cli -p 6379 CONFIG SET timeout 30延长已有键的TTL通过sentinel将流量切换到从库用脚本批量重设缓存添加随机TTL原60分钟改为55-65分钟随机事后改进在缓存客户端增加二级本地缓存对核心接口添加速率限制开发了缓存预热自动化工具5.2 热点Key问题解决某明星餐厅上线时shop:12345这个Key的QPS达到8万导致Redis单节点CPU跑满。解决方案使用Redis集群的hash tag将热点数据分散到多个节点在客户端实现本地缓存合并请求类似Facebook的Gorilla方案对热点数据增加多级缓存内存 → 进程内缓存 → Redis关键代码片段// 使用LoadingCache合并请求 LoadingCacheLong, Shop cache Caffeine.newBuilder() .refreshAfterWrite(1, TimeUnit.SECONDS) .build(id - getFromRedis(id)); // 在Nginx层做请求合并 location /api/shop { lua_shared_dict shop_cache 10m; content_by_lua_file shop_merge.lua; }6. 缓存方案选型建议6.1 决策树模型根据业务特征选择缓存策略是否要求强一致 → 是 → 只用分布式缓存 → 否 → 是否高频访问 → 是 → 多级缓存 → 否 → 本地缓存6.2 美团各业务线实践业务场景缓存方案一致性要求峰值QPS外卖订单Redis 本地缓存强一致120万用户画像多级缓存RedisES最终一致80万商家信息CDN 边缘缓存弱一致50万推荐系统本地缓存 分布式内存网格会话一致200万6.3 参数调优经验Redis连接池最大连接数建议设为QPS/1000。我们某个200万QPS的服务配置spring.redis.lettuce.pool.max-active2000 spring.redis.lettuce.pool.max-wait200ms本地缓存大小根据对象大小和GC承受能力计算。比如存储10万个User对象每个约2KBCaffeine.newBuilder() .maximumWeight(200 * 1024 * 1024) // 200MB .weigher((Long id, User user) - user.estimateSize()) .build();TTL设置技巧基础数据24小时 版本控制业务数据根据变更频率设置订单类5分钟商品类1小时热点数据短TTL10秒 自动续期在美团5年的架构优化实践中我深刻体会到没有完美的缓存方案只有最适合业务场景的权衡取舍。当你纠结技术选型时不妨先问自己这个业务能接受多长的数据延迟愿意用多少成本来保障一致性回答清楚这些问题技术方案自然水到渠成。 
长河君 · 2026/11/4 2:59:35 · 阅读 1.2k 分布式缓存与本地缓存的选型与实践指南
1. 缓存技术选型的本质思考第一次被问到为什么用分布式缓存时我正坐在美团西二旗办公室的会议室里。面试官的手指在MacBook Pro上轻轻敲击这个看似简单的问题背后实际上在考察我们对系统架构本质的理解。本地缓存就像你办公桌抽屉里的常用文件伸手就能拿到。而分布式缓存更像是公司共用的文件柜所有部门的人都能存取。当你的应用只有单个实例时用本地缓存确实就够了就像小团队共用一个办公室时抽屉就能满足需求。但美团这样的平台高峰期要处理数十万QPS的订单请求就像一个有上万员工的集团公司这时候就必须建立完善的共享存储体系。我见过不少初级开发者犯的典型错误——在微服务架构中滥用本地缓存。比如去年排查的一个优惠券系统故障就因为各个节点本地缓存不一致导致同一用户在不同服务节点看到不同的优惠券状态。这就像分公司各自维护客户资料却不及时同步必然会出现信息混乱。2. 分布式缓存的核心价值2.1 数据一致性保障分布式缓存最核心的价值在于提供了单一数据源Single Source of Truth。我们用Redis集群时所有服务节点读取的都是同一份数据。这就像集团公司使用统一的ERP系统任何部门看到的客户信息都是实时一致的。在美团外卖的业务场景中商家库存就是个典型例子。假设某餐厅最后一份黄焖鸡如果使用本地缓存用户A在节点1看到有库存并下单用户B在节点2也看到有库存并下单 这就出现了超卖。而用Redis集群存储实时库存所有请求都通过SETNX原子操作扣减就能避免这个问题。2.2 高可用与扩展性Memcached/Redis集群可以做到99.99%的可用性通过主从复制和哨兵机制实现故障自动转移。这就像大公司的文件柜有备用电源和灾备系统比个人抽屉可靠得多。当业务量增长时只需要水平扩展Redis集群节点即可。去年双十一前我们通过增加Redis分片将缓存吞吐量从5万QPS提升到20万QPS整个过程对业务无感知。而本地缓存受限于JVM内存扩展需要重启应用在美团这种体量的业务中根本不可行。3. 本地缓存的合理使用场景3.1 适合使用本地缓存的三种情况静态配置数据比如城市行政区划这类极少变更的数据。我们用一个PostConstruct加载到ConcurrentHashMap访问速度比Redis快10倍以上。防穿透保护在查询分布式缓存前先查本地缓存。我们实现了个二级缓存装饰器对不存在的商品ID缓存5秒空值去年618期间减少了30%的缓存穿透请求。高频只读数据用户基础信息这类变更频率低但读取量大的数据。我们在网关层用Caffeine缓存命中率能达到85%大幅降低下游压力。3.2 性能对比实测数据通过JMH基准测试测试环境4C8G云主机缓存类型平均耗时QPS上限内存占用HashMap28ns2000万受限于堆内存Caffeine45ns1500万可设置上限Redis1.2ms8万可扩展可以看到本地缓存的性能有数量级优势但需要接受数据不一致的风险。4. 多级缓存一致性方案4.1 美团现网采用的架构我们的多级缓存体系分为三层客户端缓存APP内缓存静态数据通过版本号控制更新网关缓存Nginx Lua实现边缘缓存TTL 1-5秒服务端缓存Redis集群 本地Caffeine4.2 一致性保障的五个关键措施失效广播机制通过Kafka发送缓存失效事件所有节点订阅处理。比如修改商品价格后会广播如下消息{ eventId: cache_evict, key: product:12345, timestamp: 1630000000 }版本号控制所有缓存数据带版本号客户端请求时必须携带本地版本。我们在HTTP头中添加X-Cache-Version: 1630000000延迟双删策略写操作时先删缓存再更新DB最后延迟500ms再删一次。代码示例public void updateProduct(Product product) { // 第一次删除 redis.del(product:product.getId()); // 更新数据库 db.update(product); // 提交延迟任务 delayQueue.add(() - { redis.del(product:product.getId()); }, 500); }binlog监听通过Canal监听MySQL binlog实时感知数据变更。我们维护了商品ID到缓存键的映射关系表当监听到update操作时自动触发缓存更新。熔断降级策略当Redis集群异常时自动降级到本地缓存并在控制台醒目告警。我们基于Hystrix实现HystrixCommand(fallbackMethod getFromLocalCache) public Product getProduct(long id) { // 正常查询Redis逻辑 }5. 典型问题排查实录5.1 缓存雪崩事故复盘去年双十一零点某品类商品缓存集中失效导致DB瞬时QPS飙升到15万。我们的处理步骤立即在运维平台执行redis-cli -p 6379 CONFIG SET timeout 30延长已有键的TTL通过sentinel将流量切换到从库用脚本批量重设缓存添加随机TTL原60分钟改为55-65分钟随机事后改进在缓存客户端增加二级本地缓存对核心接口添加速率限制开发了缓存预热自动化工具5.2 热点Key问题解决某明星餐厅上线时shop:12345这个Key的QPS达到8万导致Redis单节点CPU跑满。解决方案使用Redis集群的hash tag将热点数据分散到多个节点在客户端实现本地缓存合并请求类似Facebook的Gorilla方案对热点数据增加多级缓存内存 → 进程内缓存 → Redis关键代码片段// 使用LoadingCache合并请求 LoadingCacheLong, Shop cache Caffeine.newBuilder() .refreshAfterWrite(1, TimeUnit.SECONDS) .build(id - getFromRedis(id)); // 在Nginx层做请求合并 location /api/shop { lua_shared_dict shop_cache 10m; content_by_lua_file shop_merge.lua; }6. 缓存方案选型建议6.1 决策树模型根据业务特征选择缓存策略是否要求强一致 → 是 → 只用分布式缓存 → 否 → 是否高频访问 → 是 → 多级缓存 → 否 → 本地缓存6.2 美团各业务线实践业务场景缓存方案一致性要求峰值QPS外卖订单Redis 本地缓存强一致120万用户画像多级缓存RedisES最终一致80万商家信息CDN 边缘缓存弱一致50万推荐系统本地缓存 分布式内存网格会话一致200万6.3 参数调优经验Redis连接池最大连接数建议设为QPS/1000。我们某个200万QPS的服务配置spring.redis.lettuce.pool.max-active2000 spring.redis.lettuce.pool.max-wait200ms本地缓存大小根据对象大小和GC承受能力计算。比如存储10万个User对象每个约2KBCaffeine.newBuilder() .maximumWeight(200 * 1024 * 1024) // 200MB .weigher((Long id, User user) - user.estimateSize()) .build();TTL设置技巧基础数据24小时 版本控制业务数据根据变更频率设置订单类5分钟商品类1小时热点数据短TTL10秒 自动续期在美团5年的架构优化实践中我深刻体会到没有完美的缓存方案只有最适合业务场景的权衡取舍。当你纠结技术选型时不妨先问自己这个业务能接受多长的数据延迟愿意用多少成本来保障一致性回答清楚这些问题技术方案自然水到渠成。