目录

1、传统项目

2、微服务数据join问题

3、冗余方案

4、冗余方案之数据同步问题

5、冗余方案之字段过多

传统项目

在常规项目中，我们需要查询用户之前购买的订单列表；前端UI中会要展现出Order信息、User信息、Item商品信息。

因为Order、User、Item三张表都在一个数据库中，我们只要简单的Join即可达到我们的需求，如下图

现在的传统架构，在大型项目中的使用，越来越出现劣势。最近的微服务架构的兴起，就是明显的验证。

但微服务虽好，也会引发出一些问题，其中最主要的一个问题就是数据聚合Join问题。

微服务数据Join问题

一旦微服务化之后，数据都是分散到不同的数据库中的，那传统的数据join就不适用。那我们怎么去解决呢？

冗余方案

冗余方案方案的核心逻辑就是把关联的属性，冗余到主查询表中；和前端UI交互配合从而达到数据浅join，如下图

前端UI显示

从前端UI显示的内容看，我们只要查询Order-Service就能够满足。

1、我们可以点击用户昵称查询用户详情（可以单独请求User-Service接口）

2、我们想看商品的更多的信息，就点击商品链接，直接请求（Item-Service接口）

这样我们就可以达到，把不同数据库中的数据，聚合到一个前端UI页面中。

任何的方案，很难做到完美，冗余方案设计比较简单，但是会衍生出其他问题。

冗余方案之数据同步问题

数据同步问题是最明显的问题，即如果用户的昵称更改了，那订单表中的用户昵称如何更新？如果商品昵称和图片更改了，那订单表中的商品信息如何更新？

解决方案

1、产品业务妥协，有些业务场景，即使不更新信息，也是可以接受的。

2、采用实时同步工具，老顾开源的【彩虹桥】项目，就会实时同步更改的数据

项目地址：https://gitee.com/gujiachun/bridge.git

冗余方案之字段过多

因为业务的发展，突然哪一天还需要在订单上面显示 促销信息。那我们又要去把订单表中加入促销的字段。

时间长了后，订单表就没法看了，到处是冗余字段。

解决方案

不要在订单表上面加冗余字段，弄个关联表专门做冗余，在关联表中加入冗余字段

这样订单表就干净了。

总结

冗余方案只是一个常规的、简单的解决方式

大厂还有另一个聚合服务方案，老顾下次再介绍