java保证骆驼式交付

Question

我将Apache Camel与ActiveMQ结合使用，希望实现有保证的消息传递

我一直在阅读《骆驼行动》一书以及Apache Camel开发人员的食谱

我希望这里有人能对我的方法提出建议。我不是要代码样本

我设想的实施方式如下：

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中“死信通道”模式的文章

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

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

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

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

Answer 1

据推测，最终的目的地不是另一个ActiveMQ队列，而是可以通过异常实现的东西。你对窃听的想法在功能上与使用DLQ是一样的，所以你最好使用骆驼功能，这很好，尽可能多地做工作

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

第二，如果您只是想从重试队列中获取一条消息并重新提交，为什么不增加骆驼异常处理中的重试次数和延迟呢？这样，重试队列中的消息可能需要一些手动干预。因此，当消息位于重试队列上时，您可以手动检查/修复任何潜在原因，并手动将消息移动到输入队列