累積消息傳遞模式

Question

我在這裏尋找的設計指導比實際的解決方案更多，但同時歡迎。

這種情況是我有一個發佈者負責發佈在系統中執行的用戶更新。我的下游系統是這些更新的訂閱者。

我遇到的挑戰是上游系統的用戶經常保存他們的工作。他們這樣做的原因是因爲一個「邏輯」更新實際上涉及多個屏幕的轉換，另外對於他們來說，在其他事情上進行多任務也是很自然的，因此他們會「節省」很多。每次他們遇到保存，我們都會收到一條消息。

所以對於每個「邏輯」更新，我們可能有5-10個單獨的更新消息，其中一些可能被複制。

這會給我的下游系統的用戶造成開銷，而這些用戶正在被更新量所淹沒。對於每次更新，他們需要首先檢查它是否代表「可操作」的工作，如果這只是上游保存的結果，則丟棄它。

我知道最好的解決方案是將上游系統更改爲批量保存到一個更新中，但這樣做成本太高，因爲這將涉及供應商。

編輯：消息中沒有排序數據。因此，當我們收到更新時，無法告訴用戶在整個過程中有多「遠」。他們可以一次完成所有工作，或者他們只能完成10％的工作，並且在完成之前我們會獲得10次更新。

編輯：具體而言，我正在使用BizTalk作爲消息傳遞平臺。

編輯：我想要實現的模式是聚合器 - http://eaipatterns.com/Aggregator.html。問題是我無法知道構成輸入的一系列消息何時完成。

Answer 1

我決定實現一個聚合器模式的變體，從集合交換中選擇默認消息（最近的）。

但是，對於「觸發器」（指示聚合完成的條件集合），而不是依賴於系列的完成，我將在每天的特定時間設置服務窗口。

希望這可以幫助別人。