累积消息模式

Question

我在这里寻找设计指导而不是实际解决方案，但两者都欢迎。

场景是我有一个发布者，负责发布在系统中执行的用户更新。我的下游系统是这些更新的订阅者。

我面临的挑战是上游系统的用户定期保存他们的工作。他们这样做的原因是因为一个“合乎逻辑”的更新实际上涉及转换许多屏幕，而且他们在其他事情上多任务处理也是很自然的，因此他们经常点击“保存”。每次他们点击保存时，我们都会收到一条消息。

因此，对于每个“逻辑”更新，我们可能有 5-10 条单独的更新消息，其中一些可能是重复的。

这会给我的下游系统的用户带来开销，他们被大量的更新压得喘不过气来。对于每次更新，他们需要首先检查这是否代表“可操作”的工作，如果这只是上游保存的结果，则丢弃它。

我知道最好的解决方案是更改上游系统以将保存的内容批量保存到单个更新中，但这样做成本太高，因为这需要供应商参与。

编辑：消息中没有排序数据。因此，当我们收到更新时，无法知道用户在整个过程中“走多远”。他们本可以一口气完成所有工作，或者他们只能完成 10% 的工作，我们将在完成之前再获得 10 次更新。

编辑：特别是我使用 BizTalk 作为消息传递平台。

编辑：我想要实现的模式是聚合器 - http://eaipatterns.com/Aggregator.html。问题是我无法知道构成输入的一系列消息何时完成。

Answer 1

我决定实现聚合器模式的变体，其中默认消息（最新消息）是从集体交换中选择的。

但是，对于“触发器”（指示聚合完成的一组条件），而不是依赖于系列的完成，我将在每天的某个时间设置一个服务窗口。

希望这对其他人有所帮助。