1. JMS (Java Message Service, Java Message Service)

1.1 Definitions

The Java Message Service (JMS) API is an API for message-oriented middleware (MOM) in the Java platform, which is used to send messages between two applications or in a distributed system for asynchronous communication. Java Message Service is a platform-independent API.

1.2 Object Model of JMS

name	describe
ConnectionFactory	connection factory
Connection	connect
Session	conversation
Destination	Purpose
MessageProducer	producer
MessageConsumer	consumer
Message	information
Broker	An instance of message middleware (ActiveMQ)

1.3 JMS message model

Point-to-Point (P2P) / Peer-to-Peer
Publish/Subscribe (Pub/Sub) / Topic (pub/sub)

1.4 JMS message structure

Message header, message attributes, message body

header
Message attribute: It can be understood as an additional message header of the message, and the attribute name can be customized
Informed body

2. ActiveMQ concept

2.1 Definitions

ActiveMQ is the most popular and powerful open source message bus produced by Apache.

ActiveMQ is a JMS Provider implementation that fully supports the JMS1.1 and J2EE 1.4 specifications. Although the JMS specification has been published for a long time, JMS still plays a special role in today's J2EE applications.

2.2 Features

Supports multiple programming languages

Supports multiple transport protocols

There are multiple persistence methods

2.3 Which protocols does ActiveMQ support

ActiveMQ supports multiple protocol transmissions and transmission methods, allowing clients to connect using multiple protocols.

Protocols supported by ActiveMQ: AUTO, OpenWire, AMQP, Stomp, MQTT, etc.

Basic transport methods supported by ActiveMQ: VM, TCP, SSL, UDP, Peer, Multicast, HTTP(S), etc., as well as more advanced Failover, Fanout, Discovery, ZeroConf methods.

2.4 OpenWire Protocol

2.4.1 What is the OpenWire protocol

OpenWire is a cross-language protocol of Apache that allows access to ActiveMQ from different languages and platforms, and is the default transport protocol for versions after ActiveMQ 4.x.

2.4.2 How to use the OpenWire protocol

OpenWire supports TCP, SSL, NIO, UDP, VM and other transmission methods. To configure these connections directly is to use the OpenWire protocol. OpenWire has its own configuration parameters. The parameter names of the client and server configuration are represented by the suffix "wireFormat." .

Example

Description of OpenWire configuration parameters

Attributes	Defaults	describe
stackTraceEnabled	true	Whether the stack exception that has occurred and traced should be sent to the client through the Broker
tcpNoDelayEnabled	true	NoDelay parameter of socket
cacheEnabled	true	If repeated values are cached so that less marshalling (immediate send) occurs
tightEncodingEnabled	true	Automatically adjust the size of the transmitted content (compression ratio) according to the CPU usage
prefixPacketSize	true	Whether the size of each packet should be used as the maximum idle time for a prefix connection, in milliseconds, before each packet is marshalled (immediately to be sent).
maxInactivityDuration	30000	The broker service will close the timeout connection according to the configuration. At the same time, the connection can be maintained through the heartbeat mechanism. A value <= 0 disables monitoring of active connections.
maxlnactivityDurationInitalDelay	10000	After the connection is established, how long to start the timeout detection
cacheSize	1024	If it can be cached, then this specifies the maximum number of caches. This property was added in ActiveMQ 4.1 using the maximum frame size that can be sent
maxFrameSize	MAX_ LONG	Can help prevent OOM DOS attacks

2.5 Why use the MQTT protocol

The structure of MQTT is simple, and it is more lightweight than other message protocols. It is suitable for use in a network environment with limited computing power, low bandwidth, and unreliability.

2.5.1 MQTT's publish-subscribe model

2.5.2 MQTT Service Quality

A Quality of Service (QoS) level is a guaranteed protocol for the delivery of information between sender and receiver. There are three QoS levels in MQTT:

At most once (0)

at least once (1)

only once (2)

QoS is a major feature of MQTT that makes it easier to communicate over unreliable networks, because the protocol can control whether messages need to be resent and ensure that they arrive even in very unreliable networks. It also helps the client to freely choose QoS according to the network environment and program logic.

2.5.3 How to use the MQTT protocol in ActiveMQ

ActiveMQ server side configuration

<transportConnectors>
	<!-- DOS protection, limit concurrent connections to 1000 and frame size to 100MB -->
	<transportConnector name="mqtt" uri="mqtt://0.0.0.0:1883?maximumConnections=1000&wireFormat.maxFrameSize= 104857600"/>
</transportConnectors>

MQTT configuration parameter description

Attributes	Defaults	describe
maxFrameSize	268435456	(v5.12.0) Maximum frame size that can be sent. The protocol limit is 256MB and its value cannot be set higher. Can help prevent OOM DOS attacks

Configuration example

<transportConnector name="mqtt" uri="mtt://localhost:1883?wireFormat.maxFrameSize=100000"/>

MQTT uses NIO

<transportConnector name="mgtt+nio" uri="mtt+nio://localhost:1883"/>

MQTT uses NIO + SSL

<transportConnector name="mqtt+nio" uri="mqtt+niossl://localhost:1883"/>

2.5.4 Spring uses MQTT

Spring Integration provides support for the MQTT protocol, which can be used by adding dependencies through Maven.

<dependency>
    <groupld>org.springframework.integration</groupld>
    <artifactld>spring-integration-mqtt</artifactld>
    <version>5.1.1.RELEASE</version>
</dependency>

2.6 What is the AUTO protocol

AUTO Automatically detect protocols Starting from ActiveMQ 5.13.0, ActiveMQ supports protocol format detection, which can automatically detect OpenWire, STOMP, AMQP and MQTT. Allows these 4 types of clients to share a transport

AUTO uses TCP

<transportConnector name="auto" uri="auto://localhost:5671"/>

SSL using AUTO

<transportConnector name="auto+ssl" uri="autssl://localhost:5671"/>

Use AUTO NIO

<transportConnector name="auto+nio" uri="auto+nio://localhost:5671"/>

Use AUTO NIO + SSL

<transportConnector name="auto+nio+ssl" uri="auto+nioss://localhost:5671"/>

3. ActiveMQ high availability cluster solution

3.1 What are the cluster deployment methods of ActiveMQ?

Master-Slave deployment method	Broker-Cluster deployment method	The deployment method of the combination of Master-Slave and Broker-Cluster

3.2 Master-Slave deployment method

share the same file system

share the same database

3.3 Broker-Cluster deployment method

3.4 Deployment Method Combining Master-Slave and Broker-Cluster

4. ActiveMQ persistence mechanism

4.1 Persistence mechanism of Queue type

4.2 Topic type persistence mechanism

4.3 Storage method

4.3.1 JDBC method

Store messages into databases such as: Mysql, SQL Server, Oracle, DB2, etc.

advantage	shortcoming
Easy to manage	low performance
Can support strong consistency	/

4.3.2 AMQ method

The file-based storage method has the characteristics of fast writing speed and easy recovery. However, because it takes too long to rebuild the index, and the index file occupies too much disk space, it is no longer recommended.

advantage	shortcoming
Better performance than JDBC	Index takes up a lot of disk space
/	Reindexing is very slow

4.3.3 LevelDB method

LevelDB is a set of high-performance class libraries developed by Google for persistent data. LevelDB is not a service, and users need to implement Server by themselves. It is a single-process service, capable of processing billion-level Key-Value data and occupies a small amount of memory.

Features

Based on KV storage

Key values are stored in order

Simple operation interface

Support data snapshot

Support data compression

Structure of LevelDB

ActiveMQ configuration LevelDB : modify the configuration file ${ACTIVEMQ_HOME}/conf/activemq.xml

<persistenceAdapter>
	<levelDB directory="${activemq.data}/activemq-data"/>
</persistenceAdapter>

5. ActiveMQ transaction implementation mechanism

ActiveMQ transactions achieve eventual consistency

The producer-side implementation mechanism is as follows:

The implementation mechanism on the consumer side is as follows:

The sword refers to the message middleware ActiveMQ knowledge summary of the offer