背景

如果数据在同一个服务的同一个数据库，通过 SQL 即可查询相对比较简单，但当数据被分布到不同服务不同的数据库中时，访问组合数据的操作就变的比较困难。 针对这个问题，本文描述了服务读取不同服务的数据库的几种方法：服务间通信模式、数据缓存模式、数据复制模式、数据共享模式

本文的观点源自我在日常学习与实践过程中的思考，尚处于不断探索和验证的阶段。希望能“抛砖引玉”，激发更多的讨论与交流。让我们共同进步，在探讨与实证中寻求真知。

一、服务通信模式

如果一个服务需要读取它无法直接访问的数据库，只需要使用远程调用比如 RPC 协议访问另外一个服务即可，这也是很多团队采用的一种方式，如下图：

这看起来很简单，但技术充满挑战问题

•首先是数据网络延迟导致服务 A 性能下降。

•服务之间的耦合，为了满足服务 A 的访问量，B 服务必须随着 A 服务的流量规模变化而变化。

二、数据缓存模式

在上面服务通信的基础上加上缓存，这是很多团队使用的第二种方式。数据保存在每个服务的内存中并持续同步，因此服务拥有完全相同的数据。缓存又分为本地缓存+分布式缓存的组合关系。

1.单机本地缓存，每个服务都包含自己的数据。这种模式对应服务之间无法共享，比如服务启动加载数据到本地缓存。

2.分布式缓存：数据服务之间共享。但这种模式不是有效的复制缓存模式，因为它不能解决服务间通信模式下存在的容错性问题，获取数据从服务调用变成了缓存服务。其次由于缓存数据是中心化及共享的，打破数据所有权，并且可能导致缓存和数据库数据不一致。

以下是每种实现方式优缺点如下：

实现方式一： 本地缓存/分布式缓存+RPC 远程调用

实现方式二： 通过 RPC 服务通讯同步推送数据+本地缓存

实现方式三： 通过定时任务 worker，服务 A 通过 RPC 调用服务 B 拉数据

实现方式四： 通过异步 MQ 获取数据

缓存模式优缺点：

三、数据复制模式

在数据复制模式中，表之间会进行数据复制，也就是在数据库 A 冗余数据库 B 数据。这样可以确保服务 A 直接访问数据库 A 获取到数据库 B 的数据。可以通过很多种实现方式：

但这同样存在如下问题:如何管理数据所有权？到处都有这种数据，数据一致性问题

这种方案改善了上面服务通信的性能，容错性，可伸缩性问题。某些场景可用，比如聚合，报表或者其他不适合高性能需求，高容错性的时候

四、数据共享模式

如果上面的 3 种方式都不行，那可以用兜底方式，用创建数据领域，把数据组合到共享的数据库，让服务 A 和服务 B 都能访问。

服务之间完全解耦，解决了可用性依赖，响应性，吞吐量和可伸缩性问题

总结

1.通过本文的探讨，大家可以更全面地了解分布式数据访问的挑战和可能的解决方案

2.每种模式都有其优势和不足以及应用场景，本文旨在通过对比分析，为实际应用中的选择提供指导。

3.如果以上文案有问题或者还有更好的方案，欢迎评论区留言补充完善，谢谢