1. 问题描述：ActiveMQ Artemis 集群桥接队列消息堆积
在复杂的 activemq artemis 集群环境中，特别是当使用 2.22.0 版本时，用户可能会遇到一个棘手的问题：集群内部桥接队列 $.artemis.internal.sf 会在随机时间点出现消息堆积。尽管其他队列能够正常接收和消费消息，即使在高负载下也表现良好，但这个内部桥接队列却仿佛“卡住”了一般，导致消息无法正常转发。
这种现象通常发生在具有多层集群架构、每个集群包含多个主从节点，且消息量较大的生产环境中。尽管系统每天处理数百万条消息，且集群连接日志显示桥接状态正常，但消息堆积仍会不定期发生，与系统负载或运行时间并无必然联系，难以复现。这使得故障排查变得异常困难，通常需要手动重启实例才能恢复服务，严重影响了系统的稳定性和可用性。
2. 根本原因分析
该问题并非简单的连接断开或配置错误，而是由 ActiveMQ Artemis 2.22.0 版本中的两个关键因素共同作用导致：
2.1 producer-window-size 默认值变更
在 ActiveMQ Artemis 2.22.0 版本中，cluster-connection 配置中的 producer-window-size 默认值发生了变化。通过 ARTEMIS-3805 引入的修改，该参数的默认值从 -1（无流控窗口）变更为 1048576 字节（即 1 MiB）。
producer-window-size 参数用于控制生产者在等待确认之前可以发送到代理的最大字节数。当其值为 -1 时，表示禁用生产者流控窗口，生产者可以无限制地发送消息。当其设置为一个正值时，它限制了未确认消息的总大小。对于集群桥接而言，这意味着桥接作为消息的“生产者”，在达到 1 MiB 的未确认消息后，可能会暂停发送，直到接收方确认了部分消息。
尽管此更改在文档的“集群”章节中有所提及，但在“配置索引”章节中却遗漏了更新，这使得用户难以察觉到这一默认行为的变化。
2.2 大型消息流控缺陷
除了 producer-window-size 的默认值变更外，ActiveMQ Artemis 2.22.0 版本还存在一个未知的流控缺陷，尤其是在处理大型消息时，可能导致桥接在节点之间移动消息时卡住。这个缺陷在 ARTEMIS-4003 中被记录，并最终在 2.26.0 版本中得到了解决。
当集群桥接尝试转发大型消息时，结合 producer-window-size 的限制和这个流控缺陷，可能会导致桥接的内部状态出现异常，进而阻止消息的进一步传输，即使接收方已经准备好接收消息。
3. 解决方案
针对上述根本原因，有两种主要的方法可以解决 ActiveMQ Artemis 2.22.0 版本中集群桥接队列的消息堆积问题。
3.1 方案一：调整 producer-window-size 配置（适用于 2.22.0 版本）
如果您当前无法立即升级 ActiveMQ Artemis 版本，可以在 2.22.0 版本中通过修改 broker.xml 配置文件来解决此问题。将所有相关 cluster-connection 配置中的 producer-window-size 参数显式设置为 -1，以禁用桥接的生产者流控窗口。
操作步骤：
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 打开您的 ActiveMQ Artemis 实例的 broker.xml 配置文件。
- 定位到
部分。 - 在每个
定义中，添加或修改 producer-window-size 标签，将其值设置为 -1。
示例配置：
<cluster-connections>
<cluster-connection name="cluster-D1">
<connector-ref>connector-D1-master-a</connector-ref>
<check-period>1000</check-period>
<connection-ttl>20001</connection-ttl>
<initial-connect-attempts>-1</initial-connect-attempts>
<reconnect-attempts>1</reconnect-attempts>
<use-duplicate-detection>true</use-duplicate-detection>
<message-load-balancing>ON_DEMAND</message-load-balancing>
<max-hops>1</max-hops>
<notification-interval>2000</notification-interval>
<notification-attempts>2</notification-attempts>
<!-- 关键修改：禁用生产者流控窗口 -->
<producer-window-size>-1</producer-window-size>
<static-connectors>
<connector-ref>connector-D1-slave-a</connector-ref>
<connector-ref>connector-D1-master-b</connector-ref>
<connector-ref>connector-D1-slave-b</connector-ref>
</static-connectors>
</cluster-connection>
<!-- ... 其他 cluster-connection 配置 ... -->
</cluster-connections>注意事项：
- 将 producer-window-size 设置为 -1 意味着桥接将不受限制地发送消息。如果目标节点的消费者处理速度远低于桥接的发送速度，理论上可能导致目标节点内存压力增大。但在大多数情况下，对于内部桥接队列而言，这种设置可以有效避免流控导致的卡顿，并依赖于其他机制（如 TCP 缓冲区、网络带宽）来管理流量。
- 修改配置后，需要重启 ActiveMQ Artemis 实例以使更改生效。
3.2 方案二：升级 ActiveMQ Artemis 版本
最彻底且推荐的解决方案是将 ActiveMQ Artemis 升级到 2.26.0 或更高版本。版本 2.26.0 包含了对 ARTEMIS-4003 中描述的流控缺陷的修复，从而从根本上解决了桥接在处理大型消息时可能卡住的问题。
操作步骤：
- 查阅 ActiveMQ Artemis 官方文档，了解升级到 2.26.0 或更高版本的具体步骤和兼容性要求。
- 在测试环境中进行充分的升级测试，确保所有现有功能正常运行，且没有引入新的问题。
- 在生产环境中执行升级。
优点：
- 从根本上解决了流控缺陷，无需特殊配置。
- 通常包含其他性能改进、安全更新和错误修复。
- 遵循官方推荐的最佳实践。
注意事项：
- 版本升级可能涉及依赖项更新、配置格式变化等，需要仔细规划和测试。
- 确保在升级前备份所有重要数据和配置。
4. 总结与最佳实践
ActiveMQ Artemis 2.22.0 版本中集群桥接队列 $.artemis.internal.sf 的消息堆积问题，是 producer-window-size 默认值变更与特定流控缺陷共同作用的结果。解决此问题有两种有效途径：通过配置 producer-window-size 为 -1 来禁用桥接的生产者流控，或升级到 2.26.0 及更高版本以获得底层错误修复。
在选择解决方案时，建议优先考虑升级到最新稳定版本，因为这不仅解决了当前问题，还能受益于社区提供的持续改进和支持。如果升级暂时不可行，调整 producer-window-size 提供了一个快速有效的临时方案。
无论采用哪种方法，都应在非生产环境中进行充分的测试，以确保解决方案的有效性和稳定性。同时，持续监控 $.artemis.internal.sf 队列的消息计数和桥接连接状态，是确保 ActiveMQ Artemis 集群健康运行的关键。
