我在这里寻找设计指导而不是实际解决方案，但欢迎两者。
场景是我有一个发布者，负责发布在系统中执行的用户更新。我的下游系统是这些更新的订户。
我遇到的挑战是上游系统的用户定期保存他们的工作。他们这样做的原因是因为一个“逻辑”更新实际上涉及转换许多屏幕，而且他们在其他事情上进行多任务处理也是很自然的，因此他们会大量“节省”。每次他们点击保存，我们都会收到一条消息。
因此，对于每个“逻辑”更新，我们可能有5-10个单独的更新消息，其中一些可能是重复的。
这会导致我的下游系统的用户承受开销，他们的更新量不堪重负。对于每次更新，他们需要首先检查这是否代表“可操作”的工作，如果这只是上游保存的结果，则丢弃它。
我知道最好的解决方案是更改上游系统以将存储一起批量处理为单个更新，但这样做成本太高，因为这必须涉及供应商。
编辑：消息中没有排序数据。因此，当我们收到更新时，无法告知用户进程的“远”程度。他们本可以一次完成所有这些，或者他们只能完成10％，我们将在完成之前获得10个更新。
编辑：具体而言我使用BizTalk作为消息传递平台。
编辑：我要实施的模式是聚合器 - http://eaipatterns.com/Aggregator.html。问题是我无法知道构成输入的一系列消息何时完成。
答案 0 :(得分：0)
我决定实现聚合器模式的变体，从集体交换中选择默认消息（最新的）。
然而，对于“触发器”（指示聚合完成的条件集），而不是依赖于系列的完成，我将在每天的某个特定时间设置服务窗口。
希望这有助于其他人。