如何增加 RabbitMQ (Pika) 的取消确认重新传送时间？
兔子（Pika）如何增加重新运输时间？我们的运行时间很长，需要比默认重新传递时间更长的任务，因此，当处理完成后尝试使用ACK时，它会导致无法发送ACK错误。
How can RabbitMQ's (Pika) unack redelivery time be increased? We have a long running task that takes longer than the default redelivery time, and so when it tries to ack once the processing is finished, it's causing an unable to send ack error.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我假设您遇到了此处完整讨论的通道确认超时 - https://github.com/rabbitmq/rabbitmq-server/pull/2990#issuecomment-1002089576
像您这样的长时间运行的任务应该将正在处理的消息发布到另一个表示正在进行的工作的队列（也许每个工作人员有一个队列），然后确认原始消息。当工作完成时，消费并确认进行中队列中的消息，然后从原始队列中重新消费。
是的，这需要更多工作，但引入通道确认超时是有充分理由的。如果您知道不会遇到所描述的问题，您可以增加 RabbitMQ 配置中的超时。
I'm assuming you're running into the channel ack timeout that is discussed in full here - https://github.com/rabbitmq/rabbitmq-server/pull/2990#issuecomment-1002089576
Long-running tasks like yours should publish the message being worked on to another queue representing in-progress work (perhaps a queue per worker), then ack the original message. When the work completes, consume and ack the message in the in-progress queue, and re-consume from the original queue.
Yes it is more work but the channel ack timeout was introduced for a very good reason. If you know you won't run into the issue described, you can increase the timeout in RabbitMQ's configuration.