Artemis 持久订阅消息存储
Artemis durable subscription message storage
我想了解持久订阅在 ActiveMQ Artemis 中的工作原理。目前我最大的问题是关于存储。
我想知道消息是否重复,这意味着对于每个消费者,消息都存储在磁盘上,或者消息是否存储在一个地方,消费者只知道他们断开连接的消息并需要简历。
从我的测试中,我可以看到:对于固定的消息大小和发布的消息数量,磁盘上的 space 是相同的,无论我有 1,2 还是 3 持久订阅.我负责断开它们以便存储消息,别担心。这会让我认为队列只知道消费者回来时需要开始消费的消息的索引。
但相反,我使用 iostat cmd 检查了每秒写入字节数,我拥有的持久订阅队列越多,该统计数据增长得越多。这意味着消息重复。
你们有没有更多的信息,甚至是负责这个的源代码。
默认情况下,ActiveMQ Artemis 会将持久消息存储在一组称为 "journal." 的本地文件中,在多个队列具有相同消息的情况下(例如,在相同的 JMS 主题)实际的消息数据 仅存储一次 并且每个队列都会获得该消息的 "reference"。多次存储完全相同的消息数据会非常低效。
然而,值得注意的是,ActiveMQ Artemis 日志文件在创建时被初始化为零,这意味着即使 "empty" 日志也会占用磁盘上的 space。因此,当消息存储在日志中时,它们占用的磁盘数量 space 不会改变。现有的零将被消息数据简单地覆盖。
您可以找到 ActiveMQ Artemis on GitHub 的源代码。
如果您想查看此行为的证据,可以使用 artemis data print
命令。此命令以人类可读的格式打印日志中的原始记录。如果您要在名为 exampleTopic
和你发送一条消息,你最终会得到一个地址、2 个队列、1 条实际消息和 2 个日志中的引用。您会在 data print
命令输出中看到类似这样的内容:
********************************************
B I N D I N G S J O U R N A L
********************************************
...
### Surviving Records Summary ###
...
recordID=2;userRecordType=44;isUpdate=false;compactCount=0;PersistentAddressBindingEncoding [id=2, name=exampleTopic, routingTypes={MULTICAST}, autoCreated=false]
recordID=18;userRecordType=21;isUpdate=false;compactCount=0;PersistentQueueBindingEncoding [id=18, name=durable-client1.subscriber-1, address=exampleTopic, filterString=null, user=null, autoCreated=false, maxConsumers=-1, purgeOnNoConsumers=false, exclusive=false, lastValue=false, lastValueKey=null, nonDestructive=false, consumersBeforeDispatch=0, delayBeforeDispatch=-1, routingType=0, configurationManaged=false, groupRebalance=false, groupBuckets=-1, groupFirstKey=null, autoDelete=false, autoDeleteDelay=0, autoDeleteMessageCount=0]
recordID=23;userRecordType=21;isUpdate=false;compactCount=0;PersistentQueueBindingEncoding [id=23, name=durable-client1.subscriber-2, address=exampleTopic, filterString=null, user=null, autoCreated=false, maxConsumers=-1, purgeOnNoConsumers=false, exclusive=false, lastValue=false, lastValueKey=null, nonDestructive=false, consumersBeforeDispatch=0, delayBeforeDispatch=-1, routingType=0, configurationManaged=false, groupRebalance=false, groupBuckets=-1, groupFirstKey=null, autoDelete=false, autoDeleteDelay=0, autoDeleteMessageCount=0]
...
********************************************
M E S S A G E S J O U R N A L
********************************************
...
### Surviving Records Summary ###
recordID=27;userRecordType=45;isUpdate=false;compactCount=0;Message(messageID=27;userMessageID=41705395-b2d1-11e9-91f9-a0afbd82eaba;msg=CoreMessage[messageID=27,durable=true,userID=41705395-b2d1-11e9-91f9-a0afbd82eaba,priority=4, timestamp=Tue Jul 30 08:52:22 CDT 2019,expiration=0, durable=true, address=exampleTopic,size=232,properties=TypedProperties[__AMQ_CID=durable-client1,_AMQ_ROUTING_TYPE=0]]@454305524
recordID=27;userRecordType=32;isUpdate=true;compactCount=0;AddRef;QueueEncoding [queueID=18]
recordID=27;userRecordType=32;isUpdate=true;compactCount=0;AddRef;QueueEncoding [queueID=23]
...
我想了解持久订阅在 ActiveMQ Artemis 中的工作原理。目前我最大的问题是关于存储。
我想知道消息是否重复,这意味着对于每个消费者,消息都存储在磁盘上,或者消息是否存储在一个地方,消费者只知道他们断开连接的消息并需要简历。
从我的测试中,我可以看到:对于固定的消息大小和发布的消息数量,磁盘上的 space 是相同的,无论我有 1,2 还是 3 持久订阅.我负责断开它们以便存储消息,别担心。这会让我认为队列只知道消费者回来时需要开始消费的消息的索引。
但相反,我使用 iostat cmd 检查了每秒写入字节数,我拥有的持久订阅队列越多,该统计数据增长得越多。这意味着消息重复。
你们有没有更多的信息,甚至是负责这个的源代码。
默认情况下,ActiveMQ Artemis 会将持久消息存储在一组称为 "journal." 的本地文件中,在多个队列具有相同消息的情况下(例如,在相同的 JMS 主题)实际的消息数据 仅存储一次 并且每个队列都会获得该消息的 "reference"。多次存储完全相同的消息数据会非常低效。
然而,值得注意的是,ActiveMQ Artemis 日志文件在创建时被初始化为零,这意味着即使 "empty" 日志也会占用磁盘上的 space。因此,当消息存储在日志中时,它们占用的磁盘数量 space 不会改变。现有的零将被消息数据简单地覆盖。
您可以找到 ActiveMQ Artemis on GitHub 的源代码。
如果您想查看此行为的证据,可以使用 artemis data print
命令。此命令以人类可读的格式打印日志中的原始记录。如果您要在名为 exampleTopic
和你发送一条消息,你最终会得到一个地址、2 个队列、1 条实际消息和 2 个日志中的引用。您会在 data print
命令输出中看到类似这样的内容:
********************************************
B I N D I N G S J O U R N A L
********************************************
...
### Surviving Records Summary ###
...
recordID=2;userRecordType=44;isUpdate=false;compactCount=0;PersistentAddressBindingEncoding [id=2, name=exampleTopic, routingTypes={MULTICAST}, autoCreated=false]
recordID=18;userRecordType=21;isUpdate=false;compactCount=0;PersistentQueueBindingEncoding [id=18, name=durable-client1.subscriber-1, address=exampleTopic, filterString=null, user=null, autoCreated=false, maxConsumers=-1, purgeOnNoConsumers=false, exclusive=false, lastValue=false, lastValueKey=null, nonDestructive=false, consumersBeforeDispatch=0, delayBeforeDispatch=-1, routingType=0, configurationManaged=false, groupRebalance=false, groupBuckets=-1, groupFirstKey=null, autoDelete=false, autoDeleteDelay=0, autoDeleteMessageCount=0]
recordID=23;userRecordType=21;isUpdate=false;compactCount=0;PersistentQueueBindingEncoding [id=23, name=durable-client1.subscriber-2, address=exampleTopic, filterString=null, user=null, autoCreated=false, maxConsumers=-1, purgeOnNoConsumers=false, exclusive=false, lastValue=false, lastValueKey=null, nonDestructive=false, consumersBeforeDispatch=0, delayBeforeDispatch=-1, routingType=0, configurationManaged=false, groupRebalance=false, groupBuckets=-1, groupFirstKey=null, autoDelete=false, autoDeleteDelay=0, autoDeleteMessageCount=0]
...
********************************************
M E S S A G E S J O U R N A L
********************************************
...
### Surviving Records Summary ###
recordID=27;userRecordType=45;isUpdate=false;compactCount=0;Message(messageID=27;userMessageID=41705395-b2d1-11e9-91f9-a0afbd82eaba;msg=CoreMessage[messageID=27,durable=true,userID=41705395-b2d1-11e9-91f9-a0afbd82eaba,priority=4, timestamp=Tue Jul 30 08:52:22 CDT 2019,expiration=0, durable=true, address=exampleTopic,size=232,properties=TypedProperties[__AMQ_CID=durable-client1,_AMQ_ROUTING_TYPE=0]]@454305524
recordID=27;userRecordType=32;isUpdate=true;compactCount=0;AddRef;QueueEncoding [queueID=18]
recordID=27;userRecordType=32;isUpdate=true;compactCount=0;AddRef;QueueEncoding [queueID=23]
...