累积消息传递模式
我在这里寻求的是设计指导而不是实际的解决方案，但欢迎两者。
场景是我有一个发布者，负责发布在系统中执行的用户更新。我的下游系统是这些更新的订阅者。
我面临的挑战是上游系统的用户定期保存他们的工作。他们这样做的原因是因为一个“逻辑”更新实际上涉及转换许多屏幕，而且他们很自然地在其他事情上进行多任务处理，因此他们经常点击“保存”。每次他们点击保存时我们都会收到一条消息。
因此，对于每个“逻辑”更新，我们可能有 5-10 条单独的更新消息，其中一些可能是重复的。
这会给我的下游系统的用户带来开销，他们因大量的更新而不知所措。对于每个更新，他们需要首先检查这是否代表“可操作”的工作，如果这只是上游保存的结果，则丢弃它。
我知道最好的解决方案是更改上游系统，将保存的数据批处理到单个更新中，但这成本太高，因为这必须涉及供应商。
编辑：消息中没有排序数据。因此，当我们收到更新时，无法得知用户在该过程中“走了多远”。他们可以一次性完成所有工作，也可以只完成 10%，在完成之前我们还会收到 10 个更新。
编辑：具体来说，我使用 BizTalk 作为消息传递平台。
编辑：我想要实现的模式是聚合器 - http://eaipatterns.com/聚合器.html。问题是我无法知道组成输入的一系列消息何时完整或不完整。
I am looking for design guidance here more than actual solutions, but welcome both.
The scenario is that I have a publisher which is responsible for publishing user updates performed in a system. My downstream systems are the subscribers to these updates.
The challenge I am having is that the users of the upstream system are regularly saving their work. The reason they are doing this is because one "logical" update actually involves transitioning many screens plus it is also natural for them to be multitasking on other things and as such they hit "save" a lot. Each time they hit save we receive a message.
So For each "logical" update we have maybe 5-10 individual update messages, some of which could be duplicated.
This causes overhead for the users of my downstream systems, who are being overwhelmed with the volume of updates. For each update they need to first check if this represents an "actionable" piece of work, and discard it if this is only the result of an upstream save.
I know the best solution would be to change the upstream system to batch the saves together into a single update but this would be too costly as this would have to involve the vendor.
Edit: There are no sequencing data in the messages. So when we receive the update it there is no way of telling how "far" through the process the user is. They could have finished it all in one go, or they could only be 10% of the way through and we will get 10 more updates before they are finished.
Edit: specifically I am using BizTalk as the messaging platform.
Edit: The pattern I want to implement is the Aggregator - http://eaipatterns.com/Aggregator.html. The problem is I have no way of knowing when the series of messages which comprise the input is complete or not.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我决定实现聚合器模式的一种变体，其中默认消息（最新的）是从集体交换中选择的。
但是，对于“触发器”（表明聚合已完成的一组条件），我将在每天的某个时间设置一个服务窗口，而不是依赖于该系列的完成。
希望这对其他人有帮助。
I decided to implement a variant of the aggregator pattern whereby the default message (the most recent) is chosen from the collective interchange.
However, for the "trigger" (the set of conditions which indicate that the aggregation is complete), rather than rely on the completion of the series I will have a service window set at a certain time each day.
Hope this helps others.