读写比差异大的业务，缓存命中率多数不是被Redis性能拖垮，而是把“读多写少”和“写多读少”用同一套缓存策略硬套；先把读写路径拆开，本地缓存接读、Redis兜底、写路径少缓存或短过期，命中率就能在现有实例上明显抬升。
读写比差异大的业务，缓存命中率低怎么调优
很多团队看到缓存命中率掉下来，第一反应是升配置、加节点、上集群，读写比差异大的业务里，这个方向经常跑偏，真正要做的第一步，不是看Redis慢查询,而是把接口按读写比例分类。
- 读多写少：商品详情、内容页、配置项、用户资料展示，这类接口缓存价值最高,命中率做到覆盖大部分重复请求并不难。
- 写多读少：库存扣减、点赞计数、日志写入、会话更新，这类接口缓存收益有限,强缓存反而会增加一致性问题。
- 读写均衡：订单列表、购物车、消息已读状态，需要单独设计过期策略,不能跟读多写少混用。
缓存命中率低怎么调优，核心不是把Redis的内存再翻一倍，而是把读路径做短，读多写少接口的重复请求，相当一部分根本不需要出应用节点，可以用Caffeine这类本地缓存挡住,Redis只存跨实例共享或本地放不下的数据。
统计口径也要理清，只看Redis的keyspace_hits和keyspace_misses会漏掉本地缓存那一段，很多人抱怨“Redis命中率上不去”，其实本地缓存已经挡掉了大部分请求，Redis看到的都是miss后再回源的少量流量，调优前先按接口把总缓存命中、本地命中、Redis命中分开统计,否则容易把力气使错地方。
本地缓存和Redis对比：读写比差异大时选哪个更划算
读写比差异大时，本地缓存和Redis对比起来差异很明显，两者不是替代关系,而是分层关系。
| 维度 | 本地缓存 Caffeine/Guava | Redis |
|---|---|---|
| 访问延迟 | 微秒级，进程内直接返回 | 毫秒级，多一跳网络 |
| 多实例一致性 | 弱，需要主动失效或短TTL | 强，集中管理 |
| 适用读写比 | 读多写少、QPS高 | 读写均衡、需要共享 |
| 成本 | 只占JVM堆内存 | 独立内存与实例费用 |
| 容量 | 受单机堆限制 | 可横向扩展 |
读多写少接口如果只用Redis，所有请求都要跨网络取数据，延迟高不说，Redis规格也容易被读流量打大，把Caffeine放在应用层,读路径变成：
- 第一步：先查本地缓存,命中直接返回。
- 第二步：本地未命中,查Redis并回填本地。
- 第三步：Redis未命中，查数据库,回填Redis和本地缓存。
更新时要处理多实例一致性问题，比如商品详情价格修改后，通过Redis Pub/Sub或MQ广播一条失效消息，各实例收到后把自己本地缓存里的对应key删掉，这样既能保住读性能,又不会让旧数据长时间留存。
缓存穿透和缓存击穿怎么解决，不靠加机器
读多写少接口最怕两类问题：缓存穿透和缓存击穿，这两个问题在读写比差异大的业务里会被放大,因为大量读流量集中压在少数key上。
缓存穿透指请求查一个数据库里根本不存在的数据，缓存永远不命中，请求穿过缓存直接打库,解决方式有两种：
- 空值缓存：把“不存在”这个结果也缓存起来，TTL设短一点，比如几十秒,避免同一非法key频繁打库。
- 布隆过滤器前置：请求先过布隆过滤器，不存在的key直接返回,不用走到Redis和数据库。
缓存击穿指某个热key突然过期，一瞬间大量并发请求同时回源数据库,解决方式有两个方向：
- 互斥锁回源：用Redisson的tryLock，只允许一个请求去查数据库,其余请求等待或快速失败后重试。
- 逻辑过期：缓存的value里保存实际过期时间，key物理上不过期，读取时发现逻辑过期，先用旧值返回,同时后台异步去刷新。
写多读少的接口不能照搬空值缓存，写路径本来就频繁变化，空值缓存会把不存在的数据短暂“固定”住，等真正写入成功后还可能被旧空值拦截，写多读少场景把TTL压到秒级，或者干脆不缓存,往往比强行缓存更稳定。
北京服务器部署缓存优化方案：就近读、就近写、减少跨机房抖动
读写比差异大的业务如果部署在北京服务器，缓存节点位置会直接影响命中率和延迟，跨地域访问Redis容易出现毛刺，尤其是读多写少接口,一次网络抖动就能把接口响应拖慢几十毫秒。
- 应用与Redis同可用区部署，使用内网地址连接,不要走公网。
- 同一VPC内，北京机房Redis主从节点按读多写少比例拆分,读流量尽量走从节点。
- Caffeine前置到应用容器内，降低对机房网络质量的依赖,避免跨机房读缓存。
- 多地域部署时，北京机房做主写，其他地域做异步只读副本,地域内用本地缓存兜住大部分重复读。
具体操作路径也不复杂，在云控制台进入VPC安全组，放行Redis的6379端口；在Redis参数组里把maxmemory-policy设置成allkeys-lru，让冷key自动淘汰，改完以后用redis-cli连上实例，执行info stats观察keyspace_hits和keyspace_misses变化，配合本地缓存，读多写少接口的总命中率通常会有明显改善,不需要额外买地域间专线。
成本倒挂：先调命中率，再谈Redis扩容价格
有人会问，Redis缓存价格贵吗？单看实例费用，中小规格的Redis并不算昂贵，但如果所有读路径都压到Redis，规格会越买越大，只读副本也越加越多，读写比差异大的业务，很多扩容开销其实是策略问题,不是容量问题。
行业共识认为，缓存调优的第一原则是让读路径尽量短，而不是把Redis买到最大规格，读多写少接口如果本地缓存能覆盖大部分重复请求，Redis只需要承担跨实例共享和冷数据兜底，实例规格自然降下来,调优顺序可以这样排：
- 先统计接口读写比,找出读多写少的大头接口。
- 给这些接口加本地缓存,TTL从短到长逐步测试。
- 观察Redis的used_memory和keyspace_misses,确认是否还有必要保留大规格或只读副本。
- 写多读少接口去掉无效缓存,减少Redis写入压力和内存占用。
把缓存分层做好以后，相当一部分业务用中等偏下规格的Redis实例就能稳住，省下来的成本比直接买高配实例更实际，调优的目标不是把Redis全部换成本地缓存，而是让每一层都只干自己该干的活：本地缓存吃重复读，Redis吃共享读,数据库只吃必须回源的请求。
缓存命中率调优这件事，落到读写比差异大的业务上，从来不是“加配置”能一步解决的，把读路径和写路径分开，把本地缓存和Redis分层，把过期策略按场景拆开,命中率自然会回到合理区间。
缓存调优相关问答
读写比差异大的业务，缓存命中率低怎么调优？
先按接口统计读写比，把读多写少的路由到本地缓存加Redis二级缓存，写多读少的接口不要缓存或把TTL压到秒级，热key用互斥锁回源，冷数据用空值缓存，核心是把读写路径拆开,而不是全局调大缓存。
本地缓存和Redis对比，哪一个更适合读多写少场景？
读多写少优先用Caffeine这类本地缓存，因为访问延迟低、不占独立实例成本，需要跨实例共享或单机堆内存不够时，再用Redis做二级缓存,两者组合通常比单用Redis更省钱。
缓存穿透和缓存击穿怎么解决，不改现有服务器配置？
穿透用布隆过滤器加空值缓存，击穿用互斥锁或逻辑过期，让一个请求回源后回填，写多读少的接口不要套空值缓存，否则会把写路径污染，解决方案都落在代码和参数调整上,不依赖升配。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/647978.html
