我正在将 Apache Camel 与 ActiveMQ 结合使用，并希望实现有保证的消息传递。
我一直在阅读《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 中的“死信 channel ”模式的内容。
我的理解是，使用此模式的实现意味着，我不会自动将每条(保证)消息删除到我的“GuaranteedMessages”队列，而是放弃该方法，而是设置重新传递选项(最大尝试次数、指数延迟、重新传递延迟等)。然后，我依靠 Camel 尝试重新投递，如果它从未通过，则只需将其放在死信 channel 延迟中即可。
然后，我将有一个单独的路由，使用这个死信队列作为它的源。同样，这将是相同的模式。如果无法成功，则将消息发送回死信队列。
这听起来像是生产系统的实际实现吗？
如果我决定将每条传入消息(需要保证的消息)删除到我自己的“GuaranteeMessage”队列中，那么相信我稍后可以从队列中手动删除该特定消息是否现实？我的理解是，我必须手动浏览队列，迭代任意数量的消息，然后手动使用该消息。我不确定这种架构的可扩展性到底如何。
最佳答案
大概最终目的地不是另一个ActiveMQ队列，而是可以通过异常的东西。您对窃听的想法在功能上与使用 DLQ 相同，因此您不妨使用 Camel 功能，它工作得很好，可以完成尽可能多的工作。
不过，有两点。首先，我会使用显式队列来保存需要重试的消息，而不是使用 DLQ，因为每个代理只有一个 DLQ，并且您不希望其中出现任何其他意外情况。
其次，如果您只是要从重试队列中获取消息并重新提交它，为什么不增加 Camel 异常处理中的重试次数和延迟呢？这样，您的重试队列中就只有可能需要一些手动干预的消息。因此，当消息位于重试队列中时，您可以手动检查/修复根本原因，然后手动将消息移动到输入队列。
关于java - Camel 保证交付，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24727508/