1

我正在使用带有 ActiveMQ 的 Apache Camel，并希望实现有保证的消息传递。

我一直在阅读 Camel in Action 这本书以及 Apache Camel Developer's Cookbook。

我希望这里有人可以在我的方法中为我提供建议。我不是要代码示例。

我设想的实现方式如下：

1. Message is received on an endpoint
2. I inspect the message
3. I use the Wiretap pattern to drop it immediately on my "GuaranteedMessages" queue if the message asks for guaranteed delivery
4. I route the message to its proper destination
5. If no exceptions were encountered, I remove the message manually from the "GuaranteedMessages" queue

听起来很容易。但是，我一直在阅读 Camel 中的“死信通道”模式。

我的理解是使用这种模式的实现意味着不是自动将每个（保证的）消息放到我的“GuaranteedMessages”队列中，而是放弃这种方法，而是设置重新传递选项（最大尝试、指数延迟、重新传递延迟等） . 然后，我依靠 Camel 尝试重新交付，如果它永远无法通过，我只需将其放入死信通道延迟中即可。

然后，我将有一个单独的路由，使用这个死信队列作为它的源。同样，这将是相同的模式。如果无法成功，则将消息发送回死信队列。

这听起来像是生产系统的现实实现吗？

相反，如果我决定将每条传入消息（需要保证）放在我自己的“GuaranteeMessage”队列中，那么相信我以后可以手动从队列中删除该特定消息是否现实？我的理解是我必须手动浏览队列，遍历任意数量的消息，然后手动使用该消息。我不确定这种架构的可扩展性到底有多大。

4

1 回答 1

1

大概最终目的地不是另一个 ActiveMQ 队列，它可以通过异常。您对窃听的想法在功能上与使用 DLQ 相同，因此您不妨使用工作正常的 Camel 功能来完成尽可能多的工作。

但是，有两点。首先，我将使用显式队列来保存需要重试的消息，而不是 DLQ，因为每个代理只有一个 DLQ，并且您不希望在其上出现任何其他意外。

其次，如果您只是要从重试队列中获取消息并重新提交，为什么不增加 Camel 异常处理中的重试次数和延迟呢？这样，您的重试队列中就只有可能需要一些手动干预的消息。因此，当消息在重试队列上时，您可以手动检查/修复根本原因，然后手动将消息移动到输入队列。

于 2014-07-14T12:18:08.347 回答