跨库多表存在大量数据依赖问题的解决方案

目录

前言

1、数据冗余的方案

2、解耦业务逻辑的数据同步方案

3、最终效果

拓展

---

前言

曾经设计的一个供应链系统中，存在商品、销售订单、采购这三个服务，它们的主数据的部分结构如下所示：

商品：

ID	名称	分类	型号	生产年份	编码

订单和子订单：

订单ID	下单时间	客户	总金额	子订单ID	商品ID	单价	数量

采购单和子订单：

采购单ID	下单时间	供应商	总金额	采购子订单ID	商品ID	单价	数量

在设计这个供应链系统时，我们需要满足以下两个需求：

• 根据商品的型号/分类/生成年份/编码等查找订单；

• 根据商品的型号/分类/生成年份/编码等查找采购订单。

初期我们的方案是这样设计的：严格按照的微服务划分原则将商品相关的职责存放在商品系统中。因此，在查询订单与采购单时，如果查询字段包含商品字段，我们需要按照如下顺序进行查询：

• 先根据商品字段调用商品的服务，然后返回匹配的商品信息；

• 在订单或采购单中，通过 IN 语句匹配商品 ID，再关联查询对应的单据。

为了方便理解这个过程，订单查询流程图如下图所示：

初期方案设计完后，很快我们就遇到了一系列问题：

• 随着商品数量的增多，匹配的商品越来越多，于是订单服务中包含 IN 语句的查询效率越来越慢

• 商品作为一个核心服务，依赖它的服务越来越多，同时随着商品数据量的增长，商品服务已不堪重负，响应速度也变慢，还存在请求超时的情况

• 由于商品服务超时，相关服务处理请求经常失败。

结果就是业务方每次查询订单或采购单时，只要带上了商品这个关键字，查询效率就会很慢而且老是失败。于是，我们重新想了一个新方案——数据冗余，下面我们一起来看下。

1、数据冗余的方案

数据冗余说白了就是在订单、采购单中保存一些商品字段信息。

为了方便理解，我们借助上面实际业务场景具体说明下，看看两者的区别。

商品：

ID	名称	分类ID	型号	生产年份ID	编码