基于 RabbitMQ 的消息传递和长期运行的消费者进程 - 我需要一个更好的模式

Question

我有一个使用 RabbitMQ 队列中的消息的服务。它的主要特点是长时间运行的处理程序，处理时间可能从 5 分钟到 6 小时不等（事实上，没有真正的限制，重要的是，它通常比 RabbitMQ 推荐的默认 ack 超时 30 分钟长）。所以，为了避免确认超时，我当前的模式是：

• 收到消息
• 暂停消息消费
• 确认收到消息
• 运行进程
• 恢复消费

这是在 .net 应用程序中使用 RabbitMQ.Client 库（官方库）实现的。

这种模式的一个很大的缺点是我必须在工作完成之前确认消息。如果发生某些事情（无论出于何种原因，服务在完成之前就终止了），则不会有任何结果，也不会再有任何消息。一个简单的解决方案是设置一个巨大的超时，比如 2 天，并在工作完成后实施 ACK。但话又说回来，如果在确认之前发生了某些事情，则在超时到期之前消息不会重新排队，而 2 天的等待时间会很长。因此，“理想情况下”，我们希望有一个短暂但“可延长”的超时。这样我们就可以 收到 开始工作，同时定期说“尚未确认，但请延长超时时间”

完成后确认
• 这样，如果服务终止并且不“延长租约”，消息将在（短的，例如 10 分钟）超时到期后重新排队 - 例如，进行下一次尝试。 缺少的一件事是“请延长我的租约”API。或者我错过了什么？无论如何，请分享您对此的想法。

考虑使用单独的子系统来处理长时间运行的任务。例如，

temporal.io

支持带有心跳的无限持续时间的任务。

Answer 1