非常长的骆驼relivery政策

Question

我正在使用骆驼，我有一个业务问题。我们使用来自activemq队列的订单消息。我们要做的第一件事是检查我们的数据库，看看客户是否存在。如果客户不存在，则支持团队需要在不同的系统中填充客户。有时这可能需要10小时甚至第二天。

我的问题是如何处理这个问题。在我看来，在高层我可以将这些消息出列，将它们存储在我们的数据库中并且间隔地重新运行它们（自定义编码的解决方案），或者我可以在我们的数据库中记录错误，然后将它们返回到activemq队列长期的重新交付政策和到期时间表示，每2小时重新交付48小时。

这会节省很多代码，但我的问题是如果方法2是一种合理的方法，或者可能导致资源问题或不知道消息在哪里的问题？

Answer 1

这是一个很常见的情况。如果您想深入了解工作进展情况，那么最好使用数据库。

您的队列消耗应该非常简单：消费消息，检查客户是否存在;如果是这样的话，否则在TODO表中写一条记录。

设置一个单独的路线在定时器上运行 - 每X分钟。它应该提取TODO记录，并且对于每个记录检查客户是否存在;如果是这样的话，否则用当前时间戳（上一次重试记录）更新记录。

这使您可以清楚地了解系统的状态，然后可以将其集成到控制台中，以查看未完成作业的状态。

有几个缺点与您的选项2：

• 你依靠ActiveMQ的调度，它采用了KahaDB变种坐在你旁边正规商店，并不得与您的H兼容/一个设置（你需要一个共享文件系统）
• 你不能在没有扫描队列的情况下看到消息，这是一个反模式 - 使用队列作为数据库 - 你也可以使用数据库，特别是如果你可以预见需要有选择地删除特定的消息。