负载均衡下IBM MQ节点重启后，Spring缓存连接的影响及防丢咨询

一、不同重启场景的具体影响 #

1. MQ节点正常重启 #

• 正常重启时，MQ会主动向已建立的连接发送关闭信号，CachingConnectionFactory持有的缓存连接会被标记为失效。后续JmsTemplate获取连接时，会自动丢弃失效连接，通过负载均衡重新建立连接到可用的MQ节点。
• 正在事务中的消息：由于JmsTransactionManager管控事务，提交前的消息仍处于本地事务上下文，不会发送至已重启的节点；若提交过程中收到连接关闭通知，事务会触发回滚，后续可重试发送。

2. MQ节点强制重启（断电、强制杀进程等） #

• 这种场景下，MQ无机会发送关闭通知，CachingConnectionFactory的缓存连接会处于假活状态——TCP连接未主动断开，应用层无法感知MQ节点已下线。
• 当JmsTemplate使用该假活连接发送消息时，会抛出连接超时、发送失败等异常；若处于事务中，JmsTransactionManager会捕获异常并触发回滚。
• 要么等TCP心跳（IBM MQ默认配置心跳机制）检测到连接失效，要么等发送操作失败后，CachingConnectionFactory才会移除失效连接，后续请求会重新建立连接到可用节点。

二、确保消息不丢失的核心措施 #

1. 配置缓存连接的有效性校验策略 #

• 开启借连接时的有效性校验：设置testConnectionOnBorrow=true，每次从缓存获取连接前先校验可用性，避免使用假活连接。
• 配置闲置连接过期：设置expireConnectionsAfterIdle，自动清理闲置过久的连接，降低假活连接留存概率。

@Bean
public CachingConnectionFactory cachingConnectionFactory() {
    CachingConnectionFactory factory = new CachingConnectionFactory();
    factory.setTargetConnectionFactory(ibmMqConnectionFactory());
    factory.setTestConnectionOnBorrow(true);
    factory.setExpireConnectionsAfterIdle(30000); // 闲置30秒过期
    factory.setConnectionCacheSize(10);
    return factory;
}

2. 事务与重试机制配合 #

• 利用Spring的RetryTemplate为消息发送操作添加重试逻辑，结合JmsTransactionManager的回滚机制，确保发送失败的消息能自动重试至可用MQ节点。
• 注意控制重试次数与间隔，避免短时间内大量重试给负载均衡带来过大压力。

3. 优化负载均衡与MQ集群配置 #

• 让负载均衡器及时检测MQ节点状态（如通过TCP端口探测、MQ健康检查接口），将新连接请求路由至可用节点，避免分配至已下线节点。
• 配置MQ队列管理器为集群模式，确保消息在集群节点间同步，即使单个节点重启，消息仍可在其他节点正常存储与消费。

4. 消息持久化与事务一致性保障 #

• 确保发送的消息为持久化消息（设置deliveryMode=DeliveryMode.PERSISTENT），MQ会将消息写入磁盘，即使节点重启，消息也不会丢失。
• 严格通过JmsTransactionManager管控发送事务，仅当事务提交成功时，才确认消息发送完成；提交失败则触发回滚，杜绝半成功状态。

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