没错本地缓存应该尽量少用。

大多数业务，并不值得为了那一点性能，引入本地缓存带来的复杂度。

我自己的原则一直都是：

能用数据库扛的，绝对不用缓存。能用中央缓存扛的，绝对不用本地缓存。

这其实也是一个软件设计原则：减少依赖，降低管理复杂度。

之前我还专门写过一篇内容：

好的架构，不一定是增加组件，而是敢于删除组件。经验丰富其厉害的程序员，还有一项本事，就是知道哪些东西暂时可以不用，以便降低系统的复杂度。 很多项目发展一段时间后，总喜欢不断往里面加组件。比如： 觉得 MySQL 慢，就上 Redis。 觉得要异步，就搞 MQ。 觉得以后可能有很多规则，就先上规则引擎。 其还得意的认为，每加一个组件，是在提升架构。实际上，也是在增加系统复杂度。 比如有些业务，访问量并不高，MySQL 完全能扛住，你却还是加了一层 Redis。你有大把的优化手…2 赞同 · 4 收藏 · 0 评论 想法

感兴趣的可以去看一下。

下面我先给你看两个真实的例子。

第一个，是我以前做过的商品服务。

大促的时候，瞬时百万并发。很多人看到这个量级，第一反应就是：本地缓存肯定少不了。

实际上并不是,我们只有在大促那半个小时，才会临时开启本地缓存,平时，本地缓存一直都是关闭的。

为什么？

因为维护几十台机器上的本地缓存，让它和数据库、Redis保持一致，难度很高。

数据更新以后，要通知几十台一起更新或者删除缓存。少处理一台，就是脏数据，或者网络抖动一下，也可能出现数据不一致。

第二个例子，是亿级用户的购物车服务。

也是一样。只有品牌部门发公众号、大型促销活动、热点流量突然暴涨的时候，我们才会临时开启本地缓存。

活动结束以后，又关闭，其他时间，一直都是Redis扛。

原因还是一样。Redis已经足够快了。没有必要为了几十微秒甚至几百微秒的优化，去承担缓存一致性的复杂度。

另外还有一个很多人容易忽略的问题，就是gc问题。 本地缓存会占用JVM堆内存。如果控制不好容量，很容易导致Full GC。

当然，也可以使用堆外缓存。但我的建议是：功力不到家，不要随便用堆外缓存。

我们当时为了使用堆外缓存，是专门安排人研究了很长时间，做了很多轮压测，确认稳定以后，才敢上线。

否则，一个缓存优化，最后可能变成新的故障来源。

我个人建议是，把当前的代码进行优化，直到瓶颈真的到了，才考虑去引入缓存。