突然觉得缓存如果单独搞一套服务出来，那不是每次写代码都要业务的写一遍，缓存的也写一遍啊？

Question

觉得有点怪怪的，比如查询的代码，如果只是想在查询搞个缓存，可以直接在service类上套个springcache的@cacheable注解就搞定了，多爽哎

Answer 1

同学，你可能没理解这个业务的背景。如果只是面向c端的最普通的那种缓存架构，确实就是你说的那种，每个服务自己写缓存。但是如果是电商的商品详情页的系统架构，是要缓存一整个商品详情页的，涉及可能几十个服务的数据，如果每个服务都自己胡乱写缓存，那么缓存的控制权就放在几十个服务的负责人那里。那么负责商品详情页系统的同学，就要一个一个沟通缓存格式、后续的变动、新加一个缓存数据、等等吧，然后商品详情页系统从redis里获取几十个服务零散写入的数据，整合起来，给商品详情页提供出去。

这个过程是不可行的，会导致大量的沟通成本，而且在大团队协作里会导致经常容易出问题

你依赖的某个服务，可能来个新同学，自己没事儿把某个写缓存的代码给删了，你都不知道

所以才要打造所谓的服务闭环，就是说，几十个服务，自己不写缓存，有数据变动，发个消息到MQ，自己就不管了。然后你开发一个商品详情页系统，监听MQ，从各个服务拉取他们变动的数据，如何存缓存？什么格式？要怎么存？用什么架构？多级缓存怎么玩儿？怎么做缓存降级？全都在你一个人的掌控之中，打造了一个闭环。就是说商品详情页涉及到的各种数据的缓存，你完全可控。

要不是打造这样的服务闭环，会导致你做商品详情页的复杂缓存架构，几乎没法做，每次有一点变动就要找：商品服务、价格服务、库存服务、推荐服务、评论服务、会员服务、促销服务，等等各个方向的人开会，几乎会把自己搞死