ActiveMQ Artemis地址大小与队列持久化大小差异过大问题问询

问题详情 #

在Artemis v2.32.0中使用AddressControl和QueueControl时遇到大小统计异常：

• 搭建单多播地址仅绑定一个队列的环境，发送40万条未被消费者确认的小型字符串消息
• AddressControl#getAddressSize()返回约900MB，QueueControl#getPersistentSize()仅约300MB；调整消息数量后，队列持久化大小始终是地址大小的1/3
• 两者的消息计数均准确显示为40万条，不确定该信任哪个数值，也不清楚差异原因，仅发现AddressControl#getAddressSize()采用估算方法但无法解释3倍的巨大差异

原因解析 #

1. 统计逻辑本质差异 #

• QueueControl#getPersistentSize()：精确统计队列中持久化消息的实际磁盘占用，只计算该队列存储的消息数据（含消息体、必要元数据），是直接读取队列存储文件的真实大小。
• AddressControl#getAddressSize()：采用估算逻辑——遍历地址关联的所有绑定（包括队列），用每个绑定的消息数乘以单条消息的平均大小。但Artemis多播地址的消息默认用共享存储优化：同一条消息仅在磁盘存一份，多个队列通过引用访问，而AddressControl的估算没有考虑这个优化，会重复计算共享消息的大小。

2. 单队列场景的估算偏差 #

哪怕只绑定一个队列，Artemis内部多播地址的消息存储会保留原始消息副本（用于后续可能的队列绑定），AddressControl的估算逻辑错误地将原始存储、队列的引用存储都重复计算，最终导致估算值是实际队列存储的3倍（原始消息+队列索引+元数据的重复统计）。

3. 消息计数一致的原因 #

两者统计的是逻辑消息数，不管底层存储是否共享，地址的消息数和队列的逻辑消息数必然一致，所以计数准确无差异。

数值可信度建议 #

优先信任QueueControl#getPersistentSize()的结果：

• 它是直接读取队列磁盘文件的精确值，反映实际占用空间。
• AddressControl#getAddressSize()的估算逻辑在多播地址场景下存在设计缺陷，未适配共享存储机制，导致估算值虚高。

验证方式 #

• 直接查看Artemis数据目录下对应队列的存储文件大小，和QueueControl#getPersistentSize()的数值对比，可确认其准确性。
• 若需要地址级别的准确大小统计，可遍历地址关联的所有队列，将它们的getPersistentSize()结果求和（多播地址下多队列绑定的情况，求和结果也等于实际总磁盘占用，因为共享消息只会被计算一次）。

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