API Persistence Priority Transaction persistence mode ACK security authentication

Persistence of Active MQ

If we send messages to MQ before we have time to consume messages in MQ, but the MQ server restarts, does the message in MQ disappear? If the message is lost, the system is unstable. Then great scientists came up with a great way to keep messages persistent and avoid losing them.

KahaDB store

It is the default persistence policy. In the data/kahadb directory, four files are generated to complete message persistence

  1. Db.data is an index file for messages, which is essentially a B-tree, using the B-tree as an index to point to messages stored in db-*.log
  2. Db.redo is used for message recovery *
  3. Db -.log stores message content. New data is appended to the end of the log file as an APPEND. It is sequential writing, so message storage is faster. The default value is 32 MB. The value increases automatically when the threshold is reached
  4. Lock File lock that writes to the broker that currently has access to kahaDB for contention processing in a clustered environment

Features:

  1. Stores messages in log form.
  2. Message indexes are stored in a B-tree structure and can be updated quickly.
  3. Full support for JMS transactions.
  4. Support for multiple recovery mechanisms KahaDB can limit the size of each data file. Does not represent total data capacity.

Configuration:

<persistenceAdapter>
<! --directory: directory where data is stored. JournalMaxFileLength: File size to save messages --> 
	<kahaDBdirectory="${activemq.data}/kahadb"journalMaxFileLength="16mb"/> 
</persistenceAdapter>
Copy the code

JDBC stored

In JDBC persistence mode, the database creates three tables by default. Each table has the following functions:

  1. The activemQ_MSGS: Queue and topic messages are stored in this table
  2. Activemq_acks: Stores information about persistent subscriptions and the ID of the message received for the last persistent subscription
  3. Activemq_lock: Similar to kahadb’s Lock file, ensures that only one broker is accessing the database at any one time

ActiveMQ persists data to a database. No specific database is specified. You can use any database storage. For example, MySQL database. The following files are part of the \conf\ Activemq.xml configuration file. First define a mysql data source for mysqL-DS, then configure the jdbcPersistenceAdapter in the persistenceAdapter node and reference the data source just defined.

DataSource createTablesOnStartup Specifies whether the persistent database bean createTablesOnStartup will create tables at startup. The default value is true. \conf\activemq.xml

Beans add

<bean id="mysql-ds" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> 
  <property name="driverClassName" value="com.mysql.jdbc.Driver"/> 
  <property name="url" value="jdbc:mysql://localhost/activemq? relaxAutoCommit=true"/> 
  <property name="username" value="root"/>
  <property name="password" value="123456"/>
  <property name="maxActive" value="200"/>
  <property name="poolPreparedStatements" value="true"/> 
</bean>
Copy the code

Modify persistenceAdapter

<persistenceAdapter>
<! -- <kahaDB directory="${activemq.data}/kahadb"/> -->
	<jdbcPersistenceAdapter dataSource="#mysql-ds" createTablesOnStartup="true" /> 
</persistenceAdapter>
Copy the code

Don’t forget that mysql database relies on jar package commons-dbcp commons-pool mysql-connector-java

LevelDB storage

LevelDB has higher persistence performance than KahaDB, although KahaDB is still the default. In addition, ActiveMQ 5.9 provides LevelDB and Zookeeper based data replication mode, which is the preferred data replication scheme in master-slave mode. However, LevelDB is officially recommended by LevelDB and is no longer supported. KahaDB is recommended

Memory message store

As the name implies, memory-based message storage means that messages are stored in memory. Persistent = “false”, meaning that persistent storage is not set and stored directly in memory, set at the Broker tag. The problem is that it’s easy to lose messages. Frequent memory GC can also lead to message accumulation problems.

JDBC Message store with ActiveMQ Journal

It is a strategy used in a clustered environment. This approach overcomes the weakness of the JDBC Store, which needs to write and read libraries every time a message comes in. ActiveMQ Journal uses latency to store data to the database, caching messages in files when they arrive, and writing them to the database after a delay. Journal files can greatly reduce the number of messages that need to be written to the DB when the consumption rate of consumers can keep up with the production rate of producer messages. For example, if a producer produces 1000 messages and these 1000 messages are saved to the Journal file, if the consumer consumes more than 90% of the messages before the journal file is synchronized to the DB, Only the remaining 10% of messages need to be synchronized to DB. If the consumer is slow to consume, the journal file allows messages to be written to DB in bulk.

We can turn off persistence on the producer side

MessageProducer producer = session.createProducer(queue);
// Persistence is enabled by default
producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT); // Set it to nonpersistent
Copy the code

Execute the process

things

session.commit(); Rollback (); Roll back the things

How do you turn things on?

At the message sender

// The first argument is set to true to turn things on
Session session = connection.createSession(true, Session.AUTO_ACKNOWLEDGE);
Copy the code

Submit things

TextMessage textMessage = session.createTextMessage("hello");
// Write a message to the destination
producer.send(textMessage);
/ / need to commit
session.commit();
Copy the code

Roll back the things

For example, we have A requirement that method A and method B execute simultaneously and that both methods succeed. If one method fails, the other method needs to roll back data. For example, when we buy goods online, the backstage will deduct my payment and the inventory of goods.

try {
	pay();
	minus();
} catch (Exception e) {
	session.rollback();
}
Copy the code

Usage Scenarios:

Batch sending reduces network connection times.

To sign for model

Sign-on represents an acknowledgement that the session on the receiving end has received a message, and feedback to Broker ActiveMQ supports automatic and manual sign-on

Session.AUTO_ACKNOWLEDGE

When the client successfully returns from receiver or onMessage, the Session automatically signs for the receipt of the message from the client.

Session.CLIENT_ACKNOWLEDGE

The client signs the Message by calling the Acknowledge method of the Message. In this case, sign-in occurs at the Session level: sign-in for a consumed message automatically sign-in for all consumed receipts for that Session.

Session.DUPS_OK_ACKNOWLEDGE

Session does not have to ensure that the message is received. This pattern may cause duplicate messages, but reduces Session overhead, so it can only be used if the client can tolerate duplicate messages.