消息崩溃

Question

我正在尝试确定Azure Service Bus是否有办法提供邮件折叠。具体来说，我喜欢这样的事情：

1. 队列中的第一个事件会被立即拾取
2. 在接下来的N秒内排队的所有其他事件，并匹配某些条件（例如匹配消息ID），将计划入队设置为一个值，以便它们在N秒结束时触发。如果已存在“等待”消息，则应将其删除。
3. N秒过期后，将显示最新的预定消息并将其拾取。

基本上我需要一种方法来获得一个好的时间到第一个事件，但提供保护，防止来自聊天来源的过度处理事件。

有没有人有他们习惯于接近这些语义的模式？

更新1

所涉及的消息不是真正的重复，而是它们是用于某些处理的实体的当前状态（例如，每次更新文件时生成的消息）。处理早期消息的结果完全被后来消息的结果所取代（例如，结果是文件的大小）。所以我们仍然需要保证我们处理最新的消息，但是在N秒内处理所有M是浪费。

Answer 1

听起来你在谈论Duplicate Detection，特别是在匹配MessageIds方面。如果你想评估邮件中的其他一些属性是否有重复检测，也许值得退后一步并询问为什么我的发布者发送了这么多重复的邮件？如果这是不可避免的，也许你可以将你的聊天消费者分成一个单独的消费者群体并手动处理重复检查，然后重新入队（只是大声思考）。