Shulou(Shulou.com)06/01 Report--

This article mainly introduces the relevant knowledge of "how Docker builds ActiveMQ message service". The editor shows you the operation process through an actual case. The operation method is simple, fast and practical. I hope this article "how Docker builds ActiveMQ message service" can help you solve the problem.

Concept

Jms message mode

Point-to-point or queue mode

Contains three roles: message queue (queue), sender (sender), and receiver (receiver). Each message is sent to a specific queue from which the recipient gets the message. Queues retain messages until they are consumed or timed out.

There is only one consumer per message, that is, once consumed, the message is no longer in the message queue.

There is no time dependence between the sender and the receiver, that is, when the sender sends the message, it does not affect the message being sent to the queue, regardless of whether the receiver is running or not.

The receiver needs to reply successfully to the queue after successfully receiving the message.

Pub/sub publish / subscribe model

Contains three roles: topic (topic), publisher (publisher), and subscriber (subscriber). Multiple publishers send messages to topic, and the system delivers these messages to multiple subscribers.

There can be multiple consumers per message

There is a time dependence between publishers and subscribers. For subscribers to a topic (topic), it must create a subscriber before it can consume the publisher's messages.

In order to consume messages, subscribers must keep running.

To ease this strict time correlation, jms allows subscribers to create a persistent subscription. In this way, even if the subscriber is not activated (running), it can receive messages from the publisher.

If you want the message to be sent without any processing, or by only one messenger, or by multiple consumers, you can use the pub/sub model.

Basic components of jms messages

Connectionfactory

Create a factory for connection objects for two different jms message models, queueconnectionfactory and topicconnectionfactory. You can find connectionfactory objects through jndi.

Destination

Destination means the message producer's message delivery target or message consumer's message source. For message producers, its destination is a queue (queue) or a topic (topic); for message consumers, its destination is also a queue or topic (that is, a message source).

So, destination is actually two types of objects: queue and topic can find destination through jndi.

Connection

Connection represents the link established between the client and the jms system (the wrapper for tcp/ip socket). Connection can produce one or more session. Like connectionfactory, there are two types of connection: queueconnection and topicconnection.

Session

Session is the interface for manipulating messages. You can create producers, consumers, messages, and so on through session. Session provides the functionality of transactions. When you need to send / receive multiple messages using session, you can put these send / receive actions into a single transaction. Similarly, it is divided into queuesession and topicsession.

The producer of the message

The message producer is created by session and used to send messages to destination. Similarly, there are two types of message producers: queuesender and topicpublisher. You can call the message producer's method (send or publish method) to send the message.

Message consumer

Message consumers are created by session to receive messages that are sent to destination. There are two types: queuereceiver and topicsubscriber. It can be created through createreceiver (queue) or createsubscriber (topic) of session, respectively. Of course, the creatdurablesubscriber method of session can also be used to create persistent subscribers.

Messagelistener

Message listener. If the message listener is registered, once the message arrives, the listener's onmessage method is automatically called. Mdb (message-driven bean) in ejb is a kind of messagelistener.

Transport transmission mode

Transport supported by activemq currently includes vm transport, tcp transport, nio transport, ssl transport, peer transport, udp transport, multicast transport, http and https transport, websockets transport, failover transport, fanout transport, discovery transport, zeroconf transport and so on.

Vm transport: allows clients and broker to communicate directly within the vm, using a connection not a socket connection, but a direct method call, thus avoiding the overhead of network transmission. The application scenario is also limited to broker and the client in the same jvm environment.

Tcp transport: the client connects to the remote broker through tcp socket. Configuration syntax:

Tcp://hostname:port?transportoptions

Http and https transport: allows clients to connect using rest or ajax. This means that you can use javascript to send messages directly to activemq.

Websockets transport: allows clients to connect to broker through html5 standard websockets.

Failover transport: this is the connection mode adopted by Azure Dragon system mq. This method has the mechanism of automatic reconnection, which works on the upper layer of other transport and is used to establish reliable transmission. Allows you to configure any number of uri, and this mechanism will automatically select one of the uri to try to connect. Configuration syntax:

Failover: (tcp://localhost:61616,tcp://localhost:61617,.)? transportoptions

Fanout transport: mainly suitable for sending production messages to multiple agents. If multiple agents have loops, it may cause consumers to receive duplicate messages. Therefore, when using this protocol, it is best to send messages to multiple disconnected agents.

Persistence persistent storage

Amq message store

The default persistent storage mode of activemq 5.0.

Kaha persistence

This is a solution specifically for message persistence. It optimizes typical message usage patterns.

Jdbc persistence

Currently supported databases are: apache derby, axion, db2, hsql, informix, maxdb, mysql, oracle, postgresql, sqlserver, sybase.

Disable persistence

Persistent storage is not applied.

Cluster scheme (master / slave)

Pure master slave

No single point of failure

Do not need to rely on shared file system or shared database, use kahadb to persist storage

A master can only carry one slave.

While master is working, the message status is automatically synchronized to slave

Once master crashes, slave automatically takes over, and messages that have been sent and not yet consumed continue to be valid

After slave takes over, you must stop slave to restart the previous master

Shared file system master slave

Jdbc master slave

In configuration, there is no distinction between master and slave. Broker with multiple shared data sources forms jdbc master slave.

The broker that first grabs the resource (database lock) becomes master, and other broker regularly tries to preempt resources.

Once master crashes, other broker grabs resources, and only one eventually grabs it and immediately becomes master. Even if the previous master is restarted successfully, it can only wait as a slave.

Installation instructions

Use docker installation here to query the docker image:

Docker search activemq

Download the docker image:

Docker pull webcenter/activemq

Create & run the activemq container:

Docker run-d-- name myactivemq-p 61617 webcenter/activemq 61616-p 8162 webcenter/activemq

61616 is the container usage port for activemq (mapped to 61617), and 8161 is the web page management port (external mapping is 8162)

View the created container. If it exists, the installation is successful:

Docker ps

View the web management page:

Enter http://ip: 8162 in the browser and click manage activemq broker to enter and view using the default account / password: admin/admin.

Configure access password

Enter the docker container:

Docker exec-it myactivemq / bin/bash

The console interface sets the user name and password:

# vi jetty-realm.properties# password modification located in the root directory conf directory # username: password [, rolename...] admin: admin, admin

Configure the connection password

Edit the activemq.xml file and place it under shutdownhooks.

Modify the credentials.properties file in conf to set the password:

Activemq.username=adminactivemq.password=123456guest.password=123456

Matters needing attention

If it is a CVM, remember to open the relevant port (61617Universe 8160)

This is the end of the introduction of "Docker's method of building ActiveMQ message service". Thank you for your reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.