我接触Ehcache大概是在七年前，那时候项目里缓存方案还是一片混沌，Redis还没像今天这样烂大街。当时接手一个老系统，数据库压力大得离谱，每天早高峰CPU飙到90%以上，DBA天天在群里喊“慢查询又爆了”。后来把Ehcache加进去，配合数据库做了分层缓存，高峰期数据库负载直接降了六成。今天想跟你聊聊这套组合拳怎么打，里面有些坑我踩过，有些细节调了无数遍才摸透。
很多人一听Ehcache就觉得这是“过时技术”，毕竟现在分布式缓存才是主流。但你要明白一个事实：本地缓存和数据库之间是天然的好搭档，因为两者的访问速度差着好几个数量级。内存里取数据是纳秒级，走网络去查数据库是毫秒级，中间隔着十万八千里。Ehcache作为JVM内的堆缓存，最大的优势就是零网络开销，数据就在你眼前，伸手就拿。而数据库那边，擅长的是持久化和复杂查询，两者各司其职，配合好了才能发挥最大价值。
但问题来了，缓存和数据库之间的数据一致性怎么保证？这是所有缓存方案的命门。我见过太多团队，缓存加了，但数据经常对不上，用户投诉说“页面数据怎么变来变去”。我的经验是，别追求强一致，那是自己跟自己过不去。正确做法是采用Cache Aside Pattern，也就是旁路缓存模式。读的时候先查缓存，没命中就去数据库查，然后把数据写进缓存并设置过期时间。写的时候先更新数据库，再删除缓存，让下次读的时候重新加载。这套流程看着简单，但里面有个关键细节：更新数据库和删除缓存这两个操作不是原子的，中间可能出故障。我的建议是把删除缓存这一步放进消息队列里异步执行，或者用事务消息来兜底，这样就算删除失败，过期的缓存也会被TTL机制清掉，不至于长期脏读。
实际操作中，你还要考虑缓存的粒度问题。很多人一上来就把整个数据库表塞进缓存，结果缓存体积爆炸，GC频繁，性能反而更差。我一般会按照业务维度来划分缓存键，比如用户信息、商品详情、订单列表，每个业务模块独立管理缓存。举个例子，用户信息表有几十个字段，但页面顶部只需要用户名和头像，那就只缓存这两个字段对应的对象，而不是把整个实体类序列化进去。字段多了，序列化和反序列化的开销都会变大，而且缓存命中率也会下降，因为只要任何一个字段变了，整个缓存就得失效。
还有一个容易被忽视的点，就是缓存预热。系统刚启动的时候，缓存是空的，这时候如果有大量请求打进来，全部穿透到数据库，可能会把数据库压垮，这叫缓存雪崩。我遇到过一个真实案例，凌晨发布新版本后，缓存全部清空，早上九点上班高峰期，数据库连接池瞬间被打满，整个系统卡了十几分钟。后来我写了个预热策略：启动的时候，把热点数据提前加载进缓存，加载过程用多线程并发去查数据库，控制在几秒内完成，这样系统一上线就能扛住流量。
再说说Ehcache的配置细节。很多人用默认配置，结果性能提升有限。你要根据业务场景调整几个关键参数：一是maxEntriesLocalHeap，这个是堆内缓存的最大条目数，设太大容易撑爆堆内存，设太小命中率又低，我一般根据对象大小来估算，控制在堆内存的十分之一以内。二是timeToLiveSeconds和timeToIdleSeconds，前者是绝对过期时间，后者是空闲过期时间，正常情况下设置前者就够了，后者适合那种“经常访问但不更新”的数据。三是diskStore路径，如果堆内放不下，可以溢写到磁盘，但要注意磁盘IO比内存慢几个量级，只能作为兜底方案，不能依赖它提升性能。
还有一个实战中很管用的技巧，叫“两级缓存”策略。Ehcache作为一级缓存放在应用本地，Redis作为二级缓存放在分布式环境中，数据库在最底层。读数据的时候，先查本地，没命中再查Redis，还没有才去数据库。写数据的时候，先更新数据库，然后删除本地缓存，再删除Redis缓存。这套方案的妙处在于，本地缓存响应最快，Redis缓存能解决多个节点之间的数据共享问题，数据库只负责兜底。我做过压测，纯走数据库的QPS大概两千，加上Redis能到一万左右，再加上本地缓存，能飙到五万以上，性能提升非常明显。
但你要注意，本地缓存有个天然的缺陷，就是集群环境下的数据不一致。同一个用户请求可能被负载均衡分发到不同的节点上，如果节点A更新了缓存，节点B的缓存还是旧的，用户就会看到不一致的数据。解决思路有几种：一是缩短本地缓存的过期时间，比如30秒或者一分钟，虽然存在短暂的不一致窗口，但大多数业务能接受；二是使用Ehcache的Terracotta集群模式，让缓存数据在多个节点间同步，但这样会增加网络开销，性价比不高；三是在写操作的时候，通过Redis发布订阅机制，通知所有节点清除本地缓存，这个方案我比较推荐，实现起来也不复杂，用Redis的Pub/Sub功能就能搞定。
说下监控和调优。加了缓存不代表万事大吉，你要时刻盯着缓存的命中率、过期次数、内存占用这些指标。Ehcache本身提供了JMX支持，可以接入监控系统，我一般关注三个数据：缓存命中率（低于80%就要考虑调整配置）、平均加载时间（如果超过50毫秒，说明缓存的序列化方式可能有问题）、缓存清理次数（频繁清理说明容量设置不合理）。有一次我发现命中率突然从95%掉到70%，排查下来是因为业务方改了一条SQL，导致查询条件多了个字段，缓存key变了，之前的缓存全部失效。后来我养成了一个习惯：每次上线前，把所有查询语句和缓存key的对应关系梳理一遍，避免这种低级失误。
说实话，Ehcache和数据库的协同优化，没有一劳永逸的方案，每个系统都有自己的特点。但底层逻辑是相通的：把热数据留在离应用最近的地方，把冷数据交给数据库，用合理的失效策略保证数据最终一致，再配合监控手段持续调优。这套组合拳打好了，你的系统性能能提升一个量级，数据库也能轻松不少。别嫌Ehcache“老”，老技术能活到今天，自然有它的道理，关键是看你怎么用它。
