跨庫多表存在大量資料依賴問題有哪些解決方案？

曾經設計的乙個**鏈系統中，存在商品、銷售訂單、採購這三個服務，它們的主資料的部分結構如下所示

在設計這個**鏈系統時，我們需要滿足以下兩個需求

初期的方案是這樣設計的：嚴格按照的微服務劃分原則將商品相關的職責存放在商品系統中。因此，在查詢訂單與採購單時，如果查詢字段包含商品字段，需要按照如下順序進行查詢

為了方便理解這個過程，畫了一張訂單查詢流程圖，如下圖所示

初期方案設計完後，很快就遇到了一系列問題

結果就是業務方每次查詢訂單或採購單時，只要帶上了商品這個關鍵字，查詢效率就會很慢而且老是失敗。於是，重新想了乙個新方案——資料冗餘

資料冗餘的方案說白了就是在訂單、採購單中儲存一些商品字段資訊。為了便於理解，下面藉著上方的實際業務場景具體說明下，請注意觀察兩者之間的區別

調整架構方案後，每次查詢時，就可以不再依賴商品服務了

但是，如果商品進行了更新，我們如何同步冗餘的資料呢？在此分享 2 種解決辦法

如果商品服務每次更新商品都需要呼叫訂單與採購服務，然後再更新冗餘資料，則會出現以下兩種問題

因此，第乙個解決辦法直接被否決了，即採取的第二個解決辦法——通過訊息發布訂閱的方案，因為它存在如下 2 點優勢

此時，架構方案如下圖所示

這個方案看起來已經挺完美了，而且市面上基本也是這麼做的，不過該方案存在如下幾個問題

1.在這個方案中，僅僅儲存冗餘資料還遠遠不夠，還需要將商品分類與生產批號的清單進行關聯查詢。也就是說，每個服務不只是訂閱商品變更這一種訊息，還需要訂閱商品分類、商品生產批號變更等訊息。下面請注意檢視訂單表結構的紅色加粗部分內容

只是列舉了一部分的結構，事實上，商品表中還有很多字段存在冗餘，比如保修型別、包換型別等。為了更新這些冗餘資料，採購服務與訂單服務往往需要訂閱近十種訊息，因此，基本上需要把商品的一小半邏輯複製過來

2.每個依賴的服務需要重複實現冗餘資料更新同步的邏輯。前面講了採購、訂單及其他服務都需要依賴商品資料，因此每個服務需要將冗餘資料的訂閱、更新邏輯做一遍，最終重複的**就會很多

3.mq 訊息型別太多了：聯調時最麻煩的是 mq 之間的聯動，如果是介面聯調還好說，因為呼叫哪個伺服器的介面相對可控而且比較好追溯；如果是訊息聯調就比較麻煩，因為常常不知道某條訊息被哪台服務節點消費了，為了讓特定的伺服器消費特定的訊息，就需要臨時改動雙方的**。不過聯調完成後，經常忘了改回原**

為此，我們不希望針對冗餘資料這種非核心需求出現如此多的問題，最終決定使用乙個特別的同步冗餘資料方案

解耦業務邏輯的資料同步方案的設計思路是這樣的

此時，整個方案的架構如下圖所示

以上方案就能輕鬆解決如下兩個問題

仔細計算後，發現之前資料冗餘的方案中每個訂單都需要儲存乙份商品的冗餘資料，假設訂單總數是 n，商品總數是 m，而 n 一般遠遠大於 m。因此，在之前資料冗餘的方案中，n 條訂單就會產生 n 條商品的冗餘資料。相比之下，解耦業務邏輯的資料同步方案更省空間，因為只增加了 m 條商品的資料

此時問題又來了，如何實時同步相關表的資料呢？直接找乙個現成的開源中介軟體就可以了，不過它需要滿足支援實時同步、支援增量同步、不用寫業務邏輯、支援 mysql 之間同步、活躍度高這五點要求

根據這五點要求，在市面上找了一圈，發現了 canal、debezium、datax、databus、flinkx、bifrost 這幾款開源中介軟體，它們之間的區別如下表所示

從對比表中來看，比較貼近我們需求的開源中介軟體是 bifrost，原因如下

因此，最終使用了 bifrost 開源中介軟體，此時整個方案的架構如下圖所示

整個架構方案上線後，商品資料的同步還算比較穩定，此時商品服務的開發人員只需要關注自身邏輯，無須再關注使用資料的人。如果需要關聯使用商品資料的訂單，採購服務的開發人員也無須關注商品資料的同步問題，只需要在查詢時加上關聯語句即可，實現了雙贏

然而，唯一讓我們擔心的是 bifrost 不支援集群，沒法保障高可用性。不過，到目前為止，它還沒有出現宕機的情況，反而是那些部署多台節點負載均衡的後台服務常常會出現宕機