java - 具有 'Message Barrier' 功能的消息队列？

Question

是否有消息队列实现允许通过将“消息屏障”插入消息流来将工作分解为“批处理”？让我澄清一下。消息屏障之后的消息不应传递给队列的任何消费者，直到该屏障之前的所有消息都被消费。有点像同步点。我还希望所有消费者在到达障碍时都能收到通知。

有这样的吗？

Answer 1

我不知道现有的、广泛可用的实现，但如果你允许我提出一个非常简单、通用的实现使用代理，其中:

• 生产者写入代理队列/主题
• 代理转发到原始队列/主题直到屏障消息被代理读取，此时:
  • 代理可以通过转发屏障消息到原始主题来通知主题订阅者屏障，或者
  • 代理可以通过以下方式通知队列订阅者障碍:
    • 定期发布障碍消息，直到障碍被清除；这并不能保证所有消费者都会收到一个通知，尽管所有消费者最终都会清除障碍(有些可能会收到 0 个通知，其他 >1 个通知——这一切都取决于用于向消费者分发消息的调度程序的类型，例如，如果非循环法)
    • 使用专门的主题在每个障碍中准确地通知每个消费者一次
  • 代理停止转发来自代理队列的任何消息，直到屏障被清除，也就是说，直到原始队列清空和/或所有消费者都确认了导致屏障的所有队列/主题消息(如果有的话)
• 代理恢复转发

更新

感谢 Miklos 指出，在 JMS 下，框架不提供异步交付的确认(JMS 中所谓的“确认”纯粹是消费者方面的概念，本身不可代理。)

因此，在 JMS 下，现有的实现(针对障碍进行调整)可能已经通过“确认队列”(与原始队列相对——它是一个“请求队列”。)消费者必须通过向代理确认队列发送确认消息来确认请求的执行；在将确认消息转发给生产者之后，代理将使用确认消息来跟踪障碍何时被清除。

如果现有的实现(针对障碍进行调整)没有已经通过“确认队列”提供了应用程序级别的确认，那么您可以:

• 让代理使用 QueueBrowser，提供:
  1. 你处理的是队列而不是事件
  2. 您想在交付时同步而不是执行确认，并且
  3. 可以在第一次 交付时同步，即使请求实际上已中止并且必须重新交付(即使障碍已被清除。)我认为 Miklos 已经指出了这个问题出 IIRC。
• 否则，添加一个由代理消费的确认队列，并适配消费者向其写入确认(本质上是上面的 JMS 场景，只是代理不需要将确认消息转发给制作人，除非您的制作人需要该功能。)