当Celery的RabbitMQ broker内存不足时会抛出什么异常？如何在Celery侧检测？

触发的异常类型 #

当RabbitMQ内存占用达到高水位线后，会主动阻塞所有执行发布操作的连接，此时Celery侧会触发两类典型异常：

1. 生产者提交任务时，若未配置操作超时，会先出现长时间无响应，超时后抛出 kombu.exceptions.OperationalError 或 celery.exceptions.TimeoutError；若RabbitMQ返回明确的连接阻塞错误，会直接抛出 amqp.exceptions.PreconditionFailed，错误信息通常包含resource locked, connection blocked 或内存高水位线相关提示。
2. Celery Worker运行过程中需要向Broker发送消息确认、任务结果时触发阻塞，会在日志中打印 amqp.exceptions.ConnectionBlocked 异常，重试多次失败后Worker进程会主动退出。

连接全阻塞或Broker故障时的Celery表现 #

• 任务提交链路卡住：调用 delay()/apply_async() 提交任务时，进程无响应不返回结果，直到配置的Broker超时阈值到期才会抛出异常
• Worker无新任务消费：已经启动的Worker无法拉取队列中的新任务，日志中周期性打印broker transport error、connection reset by peer类警告
• 任务状态不更新：已提交的任务状态长时间停留在PENDING，结果后端无对应返回数据

Celery应用侧的检测方案 #

• 配置合理的超时与重试参数：在Celery配置中添加 broker_connection_timeout = 10（单位秒），在 broker_transport_options 中设置 max_retries=3，避免业务进程无限挂起，超时抛出的异常可直接接入业务告警体系
• 新增探活检测逻辑：定时向专用探活队列提交空执行逻辑的轻量任务，统计提交到收到执行结果的耗时，耗时超过阈值或抛出异常时触发告警
• 全局异常监控：在业务代码的全局异常捕获逻辑、Celery日志采集规则中，添加对 amqp.exceptions.PreconditionFailed、kombu.exceptions.OperationalError、amqp.exceptions.ConnectionBlocked 三类异常的监控，短时间内大量出现即可判定Broker出现异常
• 调用内置检测命令：周期性执行 celery -A <你的应用入口模块名> inspect ping 命令，若返回异常或超时，即可判定Broker或Worker链路故障

内容的提问来源于stack exchange，提问作者Martin Thoma