如何在RabbitMQ服务器上设置超时检测？
我正在尝试 RabbitMQ 和 这个 python 绑定。
我注意到的一件事是，如果我不干净地杀死一个消费者（模拟崩溃的程序），服务器会认为这个消费者仍然存在很长一段时间。这样做的结果是所有其他消息都将被忽略。
例如，如果您终止消费者 1 次并重新连接，则 1/2 消息将被忽略。如果你杀死另一个消费者，那么 2/3 的消息将被忽略。如果你杀死了第 3 个，那么 3/4 的消息将被忽略，依此类推。
我尝试过打开致谢功能，但似乎没有帮助。我找到的唯一解决方案是手动停止服务器并重置它。
有更好的办法吗？
如何重新创建此场景
I am trying out RabbitMQ with this python binding.
One thing I noticed is that if I kill a consumer uncleanly (emulating a crashed program), the server will think that this consumer is still there for a long time. The result of this is that every other message will be ignored.
For example if you kill a consumer 1 time and reconnect, then 1/2 messages will be ignored. If you kill another consumer, then 2/3 messages will be ignored. If you kill a 3rd, then 3/4 messages will be ignored and so on.
I've tried turning on acknowledgments, but it doesn't seem to be helping. The only solution I have found is to manually stop the server and reset it.
Is there a better way?
How to recreate this scenario
Run rabbitmq.
Unarchive this library.
Download the consumer and publisher here.
Run amqp_consumer.py twice. Run amqp_publisher.py, feeding in some data and observe that it works as expected. Messages are received round robin style.Kill one of the consumer processes with kill -9 or task manager.
Now when you publish a message, 50% of the messages will be lost.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我在 tarball 中没有看到
amqp_consumer.py或amqp_ Producer.py，因此重现错误很棘手。每当操作系统告知套接字已关闭时，RabbitMQ 都会终止连接，释放未确认的消息以重新传递给其他客户端。您的症状非常奇怪，即使是
kill -9也应该会导致 TCP 套接字被正确清理。有些人注意到，在 AMQP 客户端和服务器之间使用防火墙或 NAT 设备运行时，套接字的生存时间比应有的时间长。这可能是这里的问题，还是您在本地主机上运行所有内容？另外，您在什么操作系统上运行系统的各个组件？
预计到达时间：根据您下面的评论，我猜测当您在 Linux 上运行服务器时，您可能会在 Windows 上运行客户端。如果是这种情况，则可能是 Windows TCP 驱动程序未正确关闭套接字，这与 Unix 上的kill-9 行为不同。 （在 Unix 上，内核将正确关闭任何被杀死进程上的 TCP 连接。）
如果是这种情况，那么坏消息是 RabbitMQ 只能在套接字关闭时释放资源，因此如果客户端操作系统不这样做，它无能为力。这与几乎所有其他基于 TCP 的服务相同。
不过，好消息是，AMQP 在网络结构不可信的情况下支持“心跳”选项。您可以尝试启用心跳。启用它们后，如果服务器在可配置的时间间隔内未收到任何流量，则它会判定连接必须已断开。
然而，坏消息是，我认为 py-amqplib 目前不支持心跳。不过值得一试！
I don't see
amqp_consumer.pyoramqp_producer.pyin the tarball, so reproducing the fault is tricky.RabbitMQ terminates connections, releasing their unacknowledged messages for redelivery to other clients, whenever it is told by the operating system that a socket has closed. Your symptoms are very strange, in that even a
kill -9ought to cause the TCP socket to be cleaned up properly.Some people have noticed problems with sockets surviving longer than they should when running with a firewall or NAT device between the AMQP clients and the server. Could that be an issue here, or are you running everything on localhost? Also, what operating system are you running the various components of the system on?
ETA: From your comment below, I am guessing that while you are running the server on Linux, you may be running the clients on Windows. If this is the case, then it could be that the Windows TCP driver is not closing the sockets correctly, which is different from the kill-9 behaviour on Unix. (On Unix, the kernel will properly close the TCP connections on any killed process.)
If that's the case, then the bad news is that RabbitMQ can only release resources when the socket is closed, so if the client operating system doesn't do that, there's nothing it can do. This is the same as almost every other TCP-based service out there.
The good news, though, is that AMQP supports a "heartbeat" option for exactly these cases, where the networking fabric is untrustworthy. You could try enabling heartbeats. When they're enabled, if the server doesn't receive any traffic within a configurable interval, it decides that the connection must be dead.
The bad news, however, is that I don't think py-amqplib supports heartbeats at the moment. Worth a try, though!
RabbitMQ 在客户端确认消息已处理时没有超时：请参阅 这篇文章（整个线程可能会引起兴趣）。帖子中的一些要点：
和（我的重点）
这个问题很可能会发生，因为在客户端拉模型中，服务器更难检测到断开的连接（与活动但无响应的消费者相反），特别是当服务器似乎乐于永远等待确认时。
更新：在 Linux 上，您可以附加 SIGTERM 和/或 SIGKILL 和/或 SIGINT 的信号处理程序，并希望以有序的方式从客户端关闭连接。在 Windows 上，我相信从任务管理器关闭会调用 Win32
TerminateProcessAPI，MSDN 对此表示：这意味着可能很难有序地终止和关闭。
可能值得在 RabbitMQ 列表上使用您自己的用例来寻求确认超时。
RabbitMQ doesn't have a timeout on acknowledgements from the client that a message has been processed: see this post (the whole thread might be of interest). Some salient points from the post:
and (my emphases)
The problem might well be occurring because in a client pull model, it's harder for the server to detect a broken connection (as opposed to an alive but unresponsive consumer), particularly as the server seems happy to wait forever for an ack.
Update: On Linux, you can attach signal handlers for SIGTERM and/or SIGKILL and/or SIGINT and hopefully close down the connection in an orderly way from the client. On Windows, I believe closing from Task Manager invokes the Win32
TerminateProcessAPI, about which MSDN says:This means it might be difficult to catch termination and close down in an orderly way.
It might be worth pursuing on the RabbitMQ list with your own use case for an ack timeout.
请提供有关您已声明的组件的更多详细信息。 属性的队列
通常（并且独立于客户端实现）一旦声明客户端和代理之间的连接中断， 就应该被删除。不过，这对共享队列没有帮助。请详细说明您到底想要建模什么。
Please provide a few more specifics regarding the components you've declared. Usually (and independent of the the client implementation) a queue with the properties
should get removed as soon as the connection between the declaring client and the broker breaks up. This won't help you with shared queues, though. Please detail a bit what exactly you are trying to model.