没错本地缓存应该尽量少用。大多数业务并不值得为了那一点性能引入本地缓存带来的复杂度。我自己的原则一直都是能用数据库扛的绝对不用缓存。能用中央缓存扛的绝对不用本地缓存。这其实也是一个软件设计原则减少依赖降低管理复杂度。之前我还专门写过一篇内容好的架构不一定是增加组件而是敢于删除组件。经验丰富其厉害的程序员还有一项本事就是知道哪些东西暂时可以不用以便降低系统的复杂度。 很多项目发展一段时间后总喜欢不断往里面加组件。比如 觉得 MySQL 慢就上 Redis。 觉得要异步就搞 MQ。 觉得以后可能有很多规则就先上规则引擎。 其还得意的认为每加一个组件是在提升架构。实际上也是在增加系统复杂度。 比如有些业务访问量并不高MySQL 完全能扛住你却还是加了一层 Redis。你有大把的优化手…2 赞同 · 4 收藏 · 0 评论 想法感兴趣的可以去看一下。下面我先给你看两个真实的例子。第一个是我以前做过的商品服务。大促的时候瞬时百万并发。很多人看到这个量级第一反应就是本地缓存肯定少不了。实际上并不是,我们只有在大促那半个小时才会临时开启本地缓存,平时本地缓存一直都是关闭的。为什么因为维护几十台机器上的本地缓存让它和数据库、Redis保持一致难度很高。数据更新以后要通知几十台一起更新或者删除缓存。少处理一台就是脏数据或者网络抖动一下也可能出现数据不一致。第二个例子是亿级用户的购物车服务。也是一样。只有品牌部门发公众号、大型促销活动、热点流量突然暴涨的时候我们才会临时开启本地缓存。活动结束以后又关闭其他时间一直都是Redis扛。原因还是一样。Redis已经足够快了。没有必要为了几十微秒甚至几百微秒的优化去承担缓存一致性的复杂度。另外还有一个很多人容易忽略的问题就是gc问题。 本地缓存会占用JVM堆内存。如果控制不好容量很容易导致Full GC。当然也可以使用堆外缓存。但我的建议是功力不到家不要随便用堆外缓存。我们当时为了使用堆外缓存是专门安排人研究了很长时间做了很多轮压测确认稳定以后才敢上线。否则一个缓存优化最后可能变成新的故障来源。我个人建议是把当前的代码进行优化直到瓶颈真的到了才考虑去引入缓存。
)
