数据库连接失效时，RabbitMQ消费者不应直接basic_nack(requeue=True)触发无限重试，而应先重建DB连接、本地带退避重试（如tenacity指数退避3次），失败后basic_nack(requeue=False)入死信队列，并确保队列已正确绑定DLX。
数据库连接失效时，RabbitMQ 消费者不能直接重试消息
遇到 InterfaceError（比如 MySQL 的 “Lost connection to MySQL server during query” 或 PostgreSQL 的 “server closed the connection unexpectedly”），说明 DB 连接已断，但当前 RabbitMQ 消息的 AMQP 信道仍处于 active 状态。此时若直接调用 channel.basic_nack(requeue=True)，可能触发无限循环重投——因为下一次消费仍会走同一段 DB 初始化逻辑，大概率再次失败。
真正该做的是：先确保 DB 连接重建成功，再决定是否重试；且重试必须带退避，不能无脑轮转。
- 不要在
basic_nack后立刻basic_ack或重发，那等于跳过错误、丢弃上下文 - DB 连接池（如 SQLAlchemy 的
create_engine(pool_pre_ping=True)）必须启用健康检查，否则拿到的可能是 stale connection - 手动 ack 前，必须确认 DB 操作已真实提交或回滚完毕，否则消息状态和 DB 状态不一致
用 retry + backoff 控制重试节奏，而非依赖 RabbitMQ 自动重入队
RabbitMQ 的 requeue=True 是“原路返回队列头”，对瞬时故障（如网络抖动）有效，但对 DB 连接池整体失效无效——它不会等你修好数据库，只会让同一条消息反复撞墙。
更可控的做法是：捕获 InterfaceError 后，本地重试 2–3 次，每次间隔递增（如 1s → 3s → 9s），并记录重试次数到 message header 或 payload 中。超限后才 basic_nack(requeue=False) 进死信队列。
立即学习“Python免费学习笔记（深入）”；
示例关键逻辑：
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
import time from tenacity import retry, stop_after_attempt, wait_exponential <p>@retry( stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=1, max=10), reraise=True ) def process_with_db(msg):</p><h1>此处 db_session.execute() 可能抛 InterfaceError</h1><pre class="brush:php;toolbar:false;">pass
在消费者 handler 中：
try: process_with_db(msg) channel.basic_ack(delivery_tag=tag) except InterfaceError as e:
不 requeue，由 tenacity 控制重试
raise e
except Exception as e: channel.basic_nack(delivery_tag=tag, requeue=False) # 进 DLX
避免在 consumer 线程里初始化全局 DB 连接池
常见错误：把 engine = create_engine(...) 写在模块顶层，或在 consumer 类的 __init__ 里创建 session。一旦连接池因超时/服务重启失效，后续所有消息都会复用这个坏连接。
正确姿势是：每次处理消息前，从连接池获取新 session，并用 session.execute("SELECT 1") 或 ORM 的 session.execute(text("SELECT 1")) 做轻量探活（配合 pool_pre_ping=True）。
- SQLAlchemy 推荐配置：
create_engine(url, pool_pre_ping=True, pool_recycle=3600) - 不要在 handler 外缓存
session实例，每个消息生命周期应独占一个 session - 若用 Django，确保
django.db.connection.close()在每次消费后调用，避免复用旧连接
死信队列（DLX）不是兜底，而是诊断入口
进 DLX 的消息不是“失败了”，而是“需要人工介入判断”。如果大量消息进 DLX，说明你的 DB 故障没被前置发现，或者重试策略太激进。
建议在 DLX 消费端加一层校验：读出消息后，先 ping 一次 DB，通则尝试重放；不通则告警，而不是继续转发。
容易被忽略的一点：basic_nack(requeue=False) 后，消息进 DLX 的前提是队列声明时已绑定 DLX 和 DLK。漏配会导致消息直接被丢弃（AMQP 默认行为）。
检查方式：用 rabbitmqctl list_queues name arguments 看目标队列的 x-dead-letter-exchange 是否存在。
