用於從跨多個數據庫的單個有效負載提交多個大記錄的系統架構

Question

我是一個休息服務，我在多部分 mime 消息中收到一個大請求。 我需要將部分分開，將第一部分（標題）存儲在一個數據庫中，並將其他部分作為單獨的記錄存儲在不同的數據庫中。

一旦所有部分都在數據庫中，標題部分就可以供客戶端查詢了。

我們還沒有決定數據庫技術，雖然我們主要是一個 .net 商店，所以 sql server 是我們的首選，但不一定是我們唯一的選擇。

因為負載很大，而且我們正在談論多個數據庫，所以我不確定事務是否是一種選擇。

經紀人選項是否合適，或者我應該以某種方式使用隊列。 我正在尋找一些建築建議。

Answer 1

大多數數據庫都有提交/回滾的概念。 應該可以在應用程序中處理概念事務。 前任：

1. 接收請求並拆分成 N 個 DB 操作來執行。
2. 執行所有操作（可能出於性能原因並行）。
3. 如果全部成功，提交並響應 2XX。
4. 如果有任何失敗，回滾並以 5XX 響應。

或者，可以將請求放入隊列中，並將操作結果存儲在 DB 中。 前任：

應用程序接口

1. 在 API 處接收請求，並放入 Queue 進行處理。
2. 回復可以找到結果的地方（ https://restfulapi.net/http-status-202-accepted/ ）

后端

1. 選擇下一條消息進行處理。
2. 執行所有操作。
3. 如果全部成功，則提交全部並將 'header' 段設置為成功。
4. 如果有任何失敗，則回滾並僅將“header”段提交為失敗。

編輯：

假設消息的大小可能在 50KB-50MB 之間，那么調整設計可能是值得的。 通常有增加隊列最大消息大小的方法，但可能不建議這樣做，因為：

1. 在隊列服務器上保持較大消息的吞吐量不能很好地擴展。
2. 可能需要任意長的過程使擴展變得困難。

解決此問題的一種選擇是在應用程序級別管理事務。 前任：

應用程序接口

1. 在 API 處接收請求，並生成交易 ID。
2. 將大消息拆分為 N 個操作來執行。
3. 使用事務 ID 和一些元數據更新數據庫以了解所有操作何時完成（例如：跟蹤總數/成功/失敗）。
4. 將 N 條消息寫入相關隊列，包括事務 ID。
5. 回答可以找到結果的地方。
6. 僅當總計 = 成功時才允許客戶端查看標頭。

后端：

1. 選擇下一條消息進行處理並執行操作。
2. 成功后，增加“成功”並提交。
3. 失敗時，回滾並增加“失敗”。

如果同一事務中的先前消息的“失敗”> 0，也可能進行優化以跳過處理。