关于微服务模式下，链表join查询，根据其他表的数据查询主表数据，查询附属数据的设计想法

传统ssm架构下，所有数据都是通过join来查询的，通过join完成数据的查询和排序等操作。但是在真实的微服务场景下，不同的应用使用的不同的数据库，数据是相互隔离的。怎么完成传统场景下的join或者链表查询，链表排序呢？

如果通过接口的方式去查询数据，代价还是比较大，如果第二方服务没有启动，导致附加数据查不到，设计不合理的话，影响自己的服务使用。怎么设计让第二方服务不影响自己的服务运行，且速度，性能更高呢？

其实可以借鉴传统数据表的“冗余”设计。在主表的或者主容器中添加附属数据的记录/存储。使用消息队列来订阅附属数据的变更，收到附属数据变更的行为之后，更新主表中冗余的附加数据值，这样就解决了链表/跨服务的额外查询和排序的问题

优点：速度快，不用额外查询数据，吞吐量高

缺点：数据非强一致的（分布式服务一般都不要求强一致，性能和可用的优先级更高）

举个例子

比如微博，比如只有点赞和微博功能，点赞是一个服务，微博是一个服务。查询微博的时候，微博服务需要查询出点赞的数据之后一起返回给前端，那么微博服务可以存储每个微博的点赞数据，不用去点赞服务查询点赞数据就直接返回。另外订阅微博的点赞消息，消费该消息之后，异步修改微博缓存的冗余点赞数据