activemq消息丢失需分生产、broker、消费三端防控：生产端用同步发送+回调确认并先落库；broker端确保持久化配置与存储空间；消费端禁用autoack并手动签收；全链路通过唯一id追踪+补偿机制实现“可追”而非“不丢”。
ActiveMQ 消息丢失不是单一环节的问题，而是贯穿生产、存储、消费全链路的系统性风险。排查需分层定位，补偿需按场景设计，不能依赖某一种配置“一劳永逸”。
一、生产者端丢消息：发出去了，但没真正进队列
常见于网络抖动、连接异常中断或未等待 Broker 确认就释放资源。比如客户端调用 connection.close() 时，若服务端正因高负载阻塞（如非持久化消息刷盘耗时超 20 秒），心跳机制可能触发 SocketException，导致缓存中待处理消息被丢弃。
- 启用 Producer 的 同步发送 + 回调确认：使用
producer.send(message, new AsyncCallback() {...})，收到 ack 才认为成功；nack 或超时则重试 - 避免裸调 close()：关闭前确保所有发送完成，或改用连接池管理生命周期
- 关键业务建议先落库再发消息：将消息内容 + 状态写入本地数据库，由定时任务扫描未确认消息并重推，配合唯一 messageId 防重
二、Broker 端丢消息：进了 ActiveMQ，但没存住
核心矛盾在于“持久化”是否真正生效。非持久化消息（setDeliveryMode(DeliveryMode.NON_PERSISTENT)）只存内存，重启即失；而即使设为 PERSISTENT，若未正确配置策略或磁盘满/文件损坏，仍会失效。
- 检查
activemq.xml中<policyentry></policyentry>是否对目标 topic/queue 显式开启<persistent>true</persistent> - 确认 KahaDB 存储路径有足够空间，且
<systemusage></systemusage>中的storeUsage限额未被击穿（否则生产者阻塞、消费者卡死） - 验证消息是否真被持久化：发送后查
data/kahadb/目录下日志文件是否有新增记录；也可通过 JMX 查看对应 destination 的MemoryPercentUsage和StorePercentUsage
三、消费者端丢消息：收到了，但没真正处理完
典型诱因是开启 autoAck = true。消息一送达即自动签收，若消费者在解析、落库过程中宕机，Broker 就认为已消费完毕，不再重发。
- 强制关闭 autoAck，改用手动签收：
session.createConsumer(destination, null, false)，业务逻辑执行成功后再调message.acknowledge() - 结合 Spring JMS 时，配置
defaultRequeueRejected="false"并捕获异常，避免因未处理异常导致消息被拒绝后直接丢弃 - 对 MQTT 客户端，务必设置
cleanSession=false且 client ID 固定；同时 Broker 端需启用<mqttsubscriptionstrategy>retainedOnlyPolicy</mqttsubscriptionstrategy>保证离线消息可恢复
四、补偿机制设计：不靠“不丢”，而靠“可追”
完全杜绝丢失成本高、难度大，更务实的做法是让丢失可发现、可补救。关键在于建立端到端的消息追踪闭环。
- 每条消息附加全局唯一 ID 和时间戳，生产端记录发送日志（含状态、时间、broker 响应）
- 消费端处理完成后，向同一 MQ 或独立通道回传“处理完成”事件，与原始 ID 关联
- 后台运行比对任务：定期扫描“已发未完成”的 ID 清单，对超时未闭环的消息触发告警或自动重推
- 对订单、支付等强一致性场景，采用事务消息模式：先本地事务写订单+消息表，再异步发 MQ；失败则靠定时任务驱动补偿，成功则清理记录
