服务经过缓存传递数据，毫不推荐

《服务经过缓存传递数据，是否可行》一文引起一个服务之间“经过缓存传递数据”设计合理性的讨论。

如上图：

• service-A将数据放入cache
• service-B从cache里读取数据

这种架构设计好仍是很差，网友进行了激烈的讨论，感兴趣的同窗能够看下《服务经过缓存传递数据，是否可行》的评论，看到这么多互联网技术人对一个技术方案问题进行思考与探讨，非常开心。这里，分享下我的的观点。

先说结论

楼主旗帜鲜明的反对“服务之间经过缓存传递数据”。

核心理由

1、数据管道场景，MQ比cache更加适合

若是只是单纯的将cache做为两个服务数据通信的管道，service-A生产数据，service-B（固然，可能有service-C/service-D等）订阅数据，MQ比cache更加合适：

• MQ是互联网常见的逻辑解耦，物理解耦组件，支持1对1，1对多各类模式，很是成熟的数据通道
  画外音：详见《MQ，互联网架构解耦神器》
• 而cache反而会将service-A/B/C/D耦合在一块儿，你们要彼此协同约定key的格式，ip地址等
• MQ可以支持push，而cache只能拉取，不实时，有时延
• MQ自然支持集群，支持高可用，而cache未必
• MQ能支持数据落地，cache具有将数据存在内存里，具备“易失”性，固然，有些cache支持落地，但互联网技术选型的原则是，让专业的软件干专业的事情：nginx作反向代理，db作固化，cache作缓存，mq作通道
  
  综上，数据管道场景，MQ比cache更加适合。

2、数据共管场景，两个(多个)service同时读写一个cache实例会致使耦合

若是不是数据管道，是两个(多个)service对一个cache进行数据共管，同时读写，也是不推荐的，这些service会由于这个cache耦合在一块儿：

• 你们要彼此协同约定key的格式，ip地址等，耦合
• 约定好同一个key，可能会产生数据覆盖，致使数据不一致
• 不一样服务业务模式，数据量，并发量不同，会由于一个cache相互影响，例如service-A数据量大，占用了cache的绝大部份内存，会致使service-B的热数据所有被挤出cache，致使cache失效；又例如service-A并发量高，占用了cache的绝大部分链接，会致使service-B拿不到cache的链接，从而服务异常
  

综上，数据共管场景，多个service耦合在一个cache实例里，也是不推荐的，须要垂直拆分，实例解耦。

3、数据访问场景，两个(多个)service有读写一份数据的需求

根据服务化的原则，数据是私有的（本质也是解耦）：

• service层会向数据的需求方屏蔽下层存储引擎，分库，chace的复杂性
• 任何需求方不能绕过service读写其后端的数据
  

假设有其余service要有数据获取的需求，应该经过service提供的RPC接口来访问，而不是直接读写后端的数据，不管是cache仍是db。

综上

• 数据管道，MQ比cache更合适
• 多个服务不该该公用一个cache实例，应该垂直拆分解耦
• 服务化架构，不该该绕过service读取其后端的cache/db，而应该经过RPC接口访问

但愿逻辑是清晰的，供大伙参考，欢迎不一样的声音共同探讨。