我已经设置了RabbitMQ，以便解析来自外部API的大约20.000个请求，但它在几分钟后不断超时。它确实可以正确解析总共 20.000 个请求中的大约 20.000 个。
日志文件显示：
=INFO REPORT==== 16-Feb-2016::17:02:50 ===
accepting AMQP connection <0.1648.0> (127.0.0.1:33091 -> 127.0.0.1:5672)
=ERROR REPORT==== 16-Feb-2016::17:03:21 ===
closing AMQP connection <0.1648.0> (127.0.0.1:33091 -> 127.0.0.1:5672):
{writer,send_failed,{error,timeout}}
我已经增加了心跳值，但我无法弄清楚为什么它超时。配置为：Ubuntu 14.04、NGINX 1.8.1、RabbitMQ 3.6.0
感谢您的时间和投入！
我刚刚在 python 中解决了类似的问题。在我的例子中，这是通过减少使用者的预取计数来解决的，这样它在其接收缓冲区中排队的消息就越少。
我的理论是，消费者上的接收缓冲区已满，然后 RMQ 尝试将其他一些消息写入消费者的套接字，但由于使用者的套接字已满而无法写入。RMQ 在此套接字上阻塞，最终超时并关闭使用者上的连接。具有较小的预取队列意味着套接字接收缓冲区不会被填充，并且 RMQ 能够写入它尝试执行的任何簿记消息，因此不会在其写入时超时或关闭连接。
虽然这只是一个理论，但它似乎在我的测试中成立。
在 Python 中，可以像这样设置预取计数：
subChannel.basicQos(10);
(感谢@shawn-guo提醒我添加此代码片段(
为@tul的答案添加更多内容。
subChannel.basicQos(10);
减少使用者预取计数确实消除了此超时异常。
默认预取计数不受限制。