我使用的是芹菜3.0.18和RabbitMQ 3.0.2。我有一个任务通过使用celery.send_task发送到另一个应用程序，我可以在日志中看到send_task调用，我可以看到离开工作实例的数据包，并且当我调用tcpflow -ce -i any port 5672时，我可以查看到达RabbitMQ实例的数据集，但是，只有第一条消息到达队列。它们都有相同的路由密钥，我尝试重新创建交换和绑定，甚至创建了一个新的RabbitMQ实例，但似乎什么都不起作用。这在过去的几个月里一直很好，直到我们的AWS基础设施崩溃后，我们不得不从头开始重建RabbitMQ。奇怪的是，我在其他应用程序上使用了完全相同的设置，使用相同的broker和相同的交换、绑定和队列，并且在那里工作得很好。此外，当我使用来自管理脚本的相同调用将消息发送到同一个交换机时，它是有效的，从同一实例上的shell运行，但当它是从工作进程中的芹菜任务发送时，它不起作用。
有什么问题吗？
最终，我发现了问题所在，但不清楚这是预期的行为、芹菜错误还是RabbitMQ错误。
结果是，除了我们的应用程序任务外，我还有一个自定义日志处理程序，用于使用RabbitMQ，使用celery.send_task将日志发送到中心位置。该日志处理程序将消息发送到名为application.logger的交换机，该交换机具有application.logger.info、application.logger.warning等路由关键字，并具有将某些日志级别路由到特定队列的绑定。这种交换、绑定和队列是直接在RabbitMQ中创建的，而不是在Celery路由中定义的。
当工作人员尝试向该交换机发送消息，但该消息不存在时，Celery将记录404 NOT_FOUND错误。在那之后，使用相同连接发送到其他交换机的任务就没有送达。它们是由工作实例发送的，我们可以看到数据包到达，该连接的RabbitMQ管理屏幕甚至显示了以kb/s为单位从客户端到达的数据，但没有传递任何消息。