ActiveMQ message persistence
1. Do not use persistence
<broker persistent=
"false"
>
</broker>
Then activemq will automatically use
memory
to save messages, use
org.apache.activemq.store.memory.MemoryPersistenceAdapter to save
2. Message data disaster recovery
Master/Slave is recommended
Third, endurance
(1),
Configuring Kaha Persistence, an engine for formatting messages to files, the current ActiveMQ default message persistence engine.
Before 5.0, there was also a message persistence engine AMQ, but it has been abandoned, and Kaha is recommended.
Kaha Peristence
is a storage solution engine that persists messages to files and is part of the ActiveMQ project.
（2）、LevelDB Persistence
（4）、Replicated LevelDB Store
Typical message usage patterns tuned to provide optimal performance, which include write/read and discarded messages are saved quickly.
Data stored in Kaha is attached to the data log, and once the data is no longer useful, the log file discards that part of the data.
ActiveMQ 5.0 and above:
<broker brokerName=
"broker"
persistent=
"true"
useShutdownHook=
"false"
>
<transportConnectors>
</transportConnectors>
<persistenceAdapter>
<kahaPersistenceAdapter directory=
"activemq-data"
maxDataFileLength=
"33554432"
/>
</persistenceAdapter>
</broker>
|
, this file system was introduced after ActiveMQ 5.8. It is very similar to KahaDB and is also a file-based local database storage form, but it provides faster persistence than KahaDB. Unlike KahaDB, it does not use traditional B-trees to achieve write-ahead of log data, but uses index-based LevelDB.
|
< persistenceAdapter >
<
levelDBdirectory="activemq-data"/>
</ persistenceAdapter >
|
(3), use JDBC to persist to the database
<persistenceAdapter>
<jdbcPersistenceAdapter dataSource=
"#my-ds"
/>
</persistenceAdapter>
|
Note: my-ds database should be pre-defined
In ActiveMQ 5.9, copy and store.
It uses Apache zookeeper configured from a set of broker nodes (all the same configuration), chooses one to be the master and stores messages, and then synchronizes all other child nodes so that other child nodes update by replicating all updates to the master node.
To put it bluntly: zookeeper+ActiveMQ cluster to prevent a single node from hanging up.
|
<persistenceAdapter>
<replicatedLevelDB
directory="${activemq.data}"
replicas="2"
bind="tcp://0.0.0.0:61619"
zkAddress="127.0.0.1:2181"
zkPassword="password"
zkPath="/activemq/leveldb-stores"
/>
</persistenceAdapter>
|
A picture is worth a thousand words:
It is recommended to use this method for configuration in production.
Reference material: