CodeBuddy未覆盖重试、死信队列及幂等性机制，需分别通过配置自动重试与异常捕获、绑定DLX/DLQ、数据库唯一约束、Redis SETNX及三态状态机实现可靠性保障。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
如果您在使用 CodeBuddy 辅助设计消息队列的消费者与生产者代码时，发现其生成内容未显式涵盖重试、死信队列及幂等性机制，则说明当前输出未覆盖分布式消息系统的关键可靠性保障环节。以下是针对这三类能力的具体实现路径：
一、引入消费者端重试机制
重试机制用于应对瞬时性故障（如数据库连接抖动、下游服务短暂不可用），避免因单次失败导致消息被丢弃或直接进入死信。需区分客户端自动重试与业务逻辑内嵌重试。
1、配置消费者启用自动重试，设置最大尝试次数为3次，初始延迟5秒，退避倍数为2；
2、在消费方法中捕获所有非业务校验类异常（如IOException、TimeoutException），不主动抛出可预期的业务异常（如订单已发货）；
3、确保重试期间不执行具有副作用的写操作（如扣减库存），仅保留状态查询或幂等前置检查。
二、绑定死信交换机与队列
当消息经多次重试仍无法成功处理时，应将其路由至死信队列，避免阻塞主链路，并为人工干预或异步补偿提供入口。
1、声明一个独立的死信交换机，类型为direct，名称为dlx.exchange；
2、创建死信队列dlq.order.process.fail，设置x-dead-letter-exchange为dlx.exchange，x-dead-letter-routing-key为dlq.route；
3、将主消费队列通过参数x-dead-letter-exchange和x-dead-letter-routing-key绑定至该死信交换机；
4、编写专用消费者监听dlq.order.process.fail，记录原始消息体、错误堆栈与时间戳到日志表或告警系统。
三、基于数据库唯一约束实现幂等消费
利用数据库主键或唯一索引拒绝重复插入，是最轻量且强一致的幂等手段，适用于创建类操作（如生成支付单、登记事件流水）。
1、为每条消息提取业务主键（如order_id）与消息ID（msg_id）组合成联合唯一索引字段；
2、在消费逻辑起始处执行INSERT IGNORE INTO mq_consume_record (order_id, msg_id, status, created_at) VALUES (?, ?, 'processing', NOW())；
3、判断SQL影响行数：若为0，说明该消息已被处理，直接返回；若为1，继续执行后续业务逻辑；
4、业务执行成功后更新mq_consume_record.status为'success'，失败则设为'failed'并触发重试。
四、采用Redis原子操作实现高并发幂等控制
在超高频场景下，数据库写入可能成为瓶颈，此时可用Redis SETNX配合过期时间实现快速判重，但需防范缓存穿透与误删风险。
1、构造key为"mq:dedup:" + md5(order_id + msg_id)，value为当前时间戳；
2、执行SET key value EX 86400 NX命令，仅当key不存在时写入且设置24小时过期；
3、若返回1，表示首次处理，允许进入业务流程；若返回0，跳过本次消费；
4、在业务逻辑完成后，不再主动删除key，依赖自然过期，避免DEL操作被其他线程误删。
五、结合消息属性与状态机实现三态幂等模型
针对“处理中→成功→失败”三种状态共存的复杂场景，需引入状态持久化与条件更新，防止重试覆盖正确结果。
1、在数据库中为每条消息维护status字段，取值为'pending'、'processing'、'success'、'failed'；
2、消费开始前执行UPDATE mq_msg_log SET status = 'processing' WHERE msg_id = ? AND status = 'pending'；
3、检查UPDATE影响行数：为0则说明已被处理或正在处理，直接退出；为1则获得处理权；
4、业务执行完毕后，根据结果执行对应UPDATE：成功则SET status='success'，失败则SET status='failed'，均带WHERE msg_id = ? AND status = 'processing'条件。
