很长的骆驼重新投递政策
Very long camel redelivery policy
我正在使用 Camel，但遇到了业务问题。我们使用来自 activemq 队列的订单消息。我们做的第一件事是检查我们的数据库以查看客户是否存在。如果客户不存在，则支持团队需要将客户填充到不同的系统中。有时这可能需要 10 个小时甚至第二天。
我的问题是如何处理这个问题。在我看来，在高层次上，我可以将这些消息出列，将它们存储在我们的数据库中，并每隔一段时间重新 运行 它们（自定义编码解决方案），或者我可以注意到我们的数据库中的错误，然后 return 它们返回到 activemq 队列，具有较长的重新传递策略和到期时间，比如每 2 小时重新传递一次，持续 48 小时。
这会节省大量代码，但我的问题是方法 2 是否是一种合理的方法，或者是否会导致资源问题或不知道消息在哪里的问题？
这是一个很常见的场景。如果您想深入了解作业的进展情况，那么最好使用数据库。
你的队列消费应该很简单：消费消息，检查客户是否存在；如果是这样处理，否则在 TODO table.
中写一条记录
在计时器上设置一条通往 运行 的单独路线 - 每 X 分钟一次。它应该拉出 TODO 记录，并为每条记录检查客户是否存在；如果是这样处理，否则用当前时间戳更新记录（最后一次重试记录）。
这使您可以清楚地了解系统状态，然后您可以将其集成到控制台中以查看未完成作业的状态。
您的选项 2 有几个缺点：
- 您依赖于 ActiveMQ 调度程序，它使用与您的常规存储一起使用的 KahaDB 变体，并且可能与您的 H/A 设置不兼容（您需要共享文件系统）
- 如果不扫描队列就看不到消息本身，这是一种反模式 - 使用队列作为数据库 - 你也可以使用数据库，特别是如果你可以预期需要有选择地删除一个特定消息。
我正在使用 Camel，但遇到了业务问题。我们使用来自 activemq 队列的订单消息。我们做的第一件事是检查我们的数据库以查看客户是否存在。如果客户不存在，则支持团队需要将客户填充到不同的系统中。有时这可能需要 10 个小时甚至第二天。
我的问题是如何处理这个问题。在我看来，在高层次上，我可以将这些消息出列，将它们存储在我们的数据库中，并每隔一段时间重新 运行 它们（自定义编码解决方案），或者我可以注意到我们的数据库中的错误，然后 return 它们返回到 activemq 队列，具有较长的重新传递策略和到期时间，比如每 2 小时重新传递一次，持续 48 小时。
这会节省大量代码，但我的问题是方法 2 是否是一种合理的方法，或者是否会导致资源问题或不知道消息在哪里的问题？
这是一个很常见的场景。如果您想深入了解作业的进展情况，那么最好使用数据库。
你的队列消费应该很简单：消费消息，检查客户是否存在；如果是这样处理，否则在 TODO table.
中写一条记录在计时器上设置一条通往 运行 的单独路线 - 每 X 分钟一次。它应该拉出 TODO 记录，并为每条记录检查客户是否存在；如果是这样处理，否则用当前时间戳更新记录（最后一次重试记录）。
这使您可以清楚地了解系统状态，然后您可以将其集成到控制台中以查看未完成作业的状态。
您的选项 2 有几个缺点：
- 您依赖于 ActiveMQ 调度程序，它使用与您的常规存储一起使用的 KahaDB 变体，并且可能与您的 H/A 设置不兼容（您需要共享文件系统）
- 如果不扫描队列就看不到消息本身，这是一种反模式 - 使用队列作为数据库 - 你也可以使用数据库，特别是如果你可以预期需要有选择地删除一个特定消息。