ArtemisMQ服务临时不可用时Spring Boot发送端的最佳处理方案

你的思路不存在偏差，这是生产环境保障消息投递可靠性的标准实现方向，针对Spring Boot + ArtemisMQ的技术栈，有成熟的落地方案，无需从零开发全套逻辑。

方案1：轻量自研实现（适合业务复杂度不高的场景） #

• 优先启用Artemis客户端内置的短周期重试能力，应对临时网络抖动场景，配置示例如下：

spring:
  artemis:
    broker-url: tcp://<your-artemis-address>:61616
    user: admin
    password: admin
    retry:
      enabled: true
      max-attempts: 3
      initial-interval: 1000
      multiplier: 2
      max-interval: 5000

• 内置重试全部失败后，捕获JmsException/MessagingException，将消息内容、投递目标、重试次数、创建时间等元数据持久化到本地存储，可选择H2、SQLite等嵌入式关系型数据库，或者RocksDB等本地KV存储，保证服务重启时消息不丢失。
• 新增定时重试任务，通过@Scheduled配置周期（建议1~5分钟，可根据业务容忍度调整），批量读取本地存储中投递失败的消息尝试重发，重发成功则删除本地记录，失败则更新重试次数、下次重试时间，超过最大重试阈值后移入死信存储，触发告警通知人工介入。

方案2：基于Spring Integration的开箱即用实现（适合不想重复造轮子的场景） #

直接复用Spring Integration提供的现有能力实现自动重试和持久化：

• 配置JMS出站适配器，指定失败消息的路由通道
• 搭配持久化的MessageStore存储发送失败的消息
• 配置Poller定时拉取失败消息自动重试，框架自带了重试次数控制、死信路由等能力，无需自行开发核心逻辑。

• 消费端必须实现幂等校验：重试机制必然会带来重复投递的概率，消费端需要通过业务唯一ID等方式做幂等判断，避免重复执行业务逻辑。
• 不要设置无限重试：如果消息存在时效性，或者重试超过阈值仍失败，不要无限循环重试，避免无效占用资源，要及时触发告警人工处理。
• 本地存储要做可靠性保障：单机部署时要做好存储文件的备份，避免磁盘损坏导致未投递消息丢失；集群部署可替换为分布式KV存储，避免单节点宕机导致消息遗漏。

内容的提问来源于stack exchange，提问作者Dennis Fabri