Introduction to JMS and ActiveMQ (3) _ ActiveMQ

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/14353251N-0.jpg "title =" slide into jpg" alt = "182606887.jpg"/>

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1435325Q2-1.jpg "title =" slide 21.JPG" alt = "182631115.jpg"/>

First, we will briefly introduce ActiveMQ. ActiveMQ is an open-source free Message Server provided by the Apache Software Foundation. Its current version is 5.8.0.

ActiveMQ has the following features:

Based on the JMS 1.1 and J2EE 1.4 specifications;

Supports multiple connection protocols: HTTP/S, IP multicast, SSL, STOMP, TCP, UDP, and XMPP;

Supports multiple message persistence mechanisms: file persistence (KahaDB) and relational database persistence (JDBC );

Plug-in Security Mechanism: ActiveMQ supports plug-in development, and its security mechanism is implemented in the form of plug-ins for flexible configuration;

Supports embedding Java applications. ActiveMQ can be used as a separate service or directly embedded into other Java applications;

Integration with application servers: Apache Tomcat, Jetty, ApacheGeronimo, and Jboss are supported;

Client APIs in multiple languages: supports C/C ++,. NET, Perl, PHP, Python, Ruby, etc;

Cluster;

Dynamic and simple management.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1435322321-2.jpg "title =" slide 22.JPG" alt = "182725139.jpg"/>

ActiveMQ is developed using Java, Spring bean configuration, and Maven.

The source code directory structure of ActiveMQ 5.6.0 can be seen from the pom file that it contains 23 modules, such as the core module activemq-core and the web console module activemq-web-console, file-based message persistence module, such as kahadb.

After Maven is used for compilation and packaging, ActiveMQ in assembly/target generates an executable package.

ActiveMQ execution package directory structure:

The bin directory contains the startup script;

The conf directory is a configuration file;

The data directory contains persistent message files;

Webapps is the web Console Directory.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/143532B33-3.jpg "title =" slide 23.JPG" alt = "182753867.jpg"/>

The ActiveMQ service can be started using scripts in the bin directory. From the configuration file, we can see that the ActiveMQ service is also configured through Spring. The entire configuration file is essentially to configure a broker instance, from the namespace, we can see that the ActiveMQ broker instance is actually an org. apache. activemq. xbean. XBeanBrokerService class, And XBeanBrokerService inherits from org. apache. activemq. broker. brokerService, which is a core class in ActiveMQ, is used to provide message service externally.

The configuration of ActiveMQbroker includes the following parts:

Destination policy: used to configure policies for destination queues and topics, including traffic control and distribution policies;

JMX management: used to configure JMX;

Persistence settings:

Storage settings:

Connector settings:

Web console settings: ActiveMQ uses embedded Jetty to provide a Web console for visual management of connections, topics, queues, and consumers.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1435322M7-4.jpg "title =" slide 24.JPG" alt = "182818367.jpg"/>

In ActiveMQ, the address name of a queue or topic can be expressed in a comma separated manner, such as queue. news. subject0-10.

ActiveMQ supports the use of wildcards to represent the addresses of a queue and topic. The wildcards include:

., Used to split the name in the address;

*, Used to match any character;

>, Used to match any character.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/143532OF-5.jpg "title =" slide 25.JPG" alt = "182900216.jpg"/>

A destination policy contains multiple policy entities. A policy entity can describe a queue or topic policy, or describe a queue or topic policy by using wildcards.

As shown in the preceding example, the policy object configures all topics and controls the traffic of each topic. The memory limit is 1 MB, and Message Reference is saved in the memory.

Some attributes of the Policy entity are listed below. All attributes can be viewed on the ActiveMQ official website.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1435325O2-6.jpg "title =" slide 26.JPG" alt = "182934302.jpg"/>

The policy entity also contains some sub-tags used to set specific policies. The following lists some sub-tags:

Message distribution policy;

Dead-letter queue policy: when a message is repeatedly sent but fails to be sent multiple times, ActiveMQ will send a message to the dead-letter queue. The dead-letter queue policy configures this operation, for example, you can use a shared dead-letter queue or a separate dead-letter queue;

Message revocation policy: this policy is used when a message needs to be deleted when the message consumption is slow, for example, canceling the longest message;

Message quantity limit policy: used to set the maximum number of persistent messages;

Subscription recovery policy: used when the subscriber reconnects, for example, only the last message is restored;

Persistent subscription refers to the Message Reference Policy, the Message Reference Policy of the queue, and the Message Reference Policy of the subscriber: used to set the storage location of the Message application, such as storing the Message Reference in the memory;

Slow Consumer Policy: used when message consumption is slow, for example, exiting directly.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1435323235-7.jpg "title =" slide 27.JPG" alt = "183006776.jpg"/>

Next we will introduce the distribution policy in detail.

First, we will introduce the pre-read mechanism. To increase the speed of message consumption, ActiveMQ pushes as many messages as possible to consumers through the pre-read mechanism and caches them on the Consumer Client.

To prevent consumer cache overflow, ActiveMQ uses prefetchlimit to control the number of messages currently pushed to the consumer and no confirmation is received.

The default value of prefetch limit is: Persistent message queue is 1000, non-persistent message queue is 1000, persistent message topic is 100, and non-persistent message topic is-1.

If prefetch limit = 1, the consumer receives only one message at a time, which is equivalent to disabling the pre-read mechanism.

If prefetchlimit = 0, the message is received only when the consumer actively pulls the message, instead of pushed to the consumer.

The following policies are specific to the distribution policy. The roundRobin policy distributes messages evenly to consumers when multiple consumers exist, instead of using the pre-read mechanism, all messages are sent to a consumer until the prefetch limit is reached. Instead, the strictOrder policy sends all messages to a consumer first. However, this policy ensures that when there are multiple message producers and multiple message consumers in the topic, each message consumer receives the same order of messages.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1435322C6-8.jpg "title =" slide 28.JPG" alt = "183117841.jpg"/>

Traffic control is designed to prevent fast message production and slow consumption, leading to congestion of queues or topics.

Before ActiveMQ5.0, ActiveMQ used the traffic control mechanism of the TCP protocol. The disadvantage of this method was that it could only control the traffic of the entire connection, but not the traffic control of a single producer, in addition, when multiple message producers and consumers use the same connection, a deadlock may occur.

Starting from ActiveMQ5.0, ActiveMQ supports Traffic Control for a single producer. Traffic control can be configured on the producer client and server.

If the producer client asynchronously sends the message useAsyncSend to true), the thread does not block when sending the message and waits for the Message Server to return confirmation. In this case, you need to configure traffic control on the producer client and set a maximum value through setProducerWindowSize, that is, the maximum number of unreceived messages sent by the producer cannot be exceeded. If the maximum number is exceeded, wait.

The server traffic control is configured in two places:

1) in the destination policy, you can use producerFlowControl to set whether traffic is controlled for each destination. memoryLimit indicates the maximum number of messages stored in the memory, and vmCursor indicates that only the cursor of messages is saved in the memory, in this way, you can store as many messages as possible in the memory.

2) In the storage settings, you can configure the storage usage of the entire message server. memoryUsage indicates the memory used by ActiveMQ, and storeUsage indicates the size of the persistent message storage file, tempUsage indicates the file size of non-persistent message storage. In the storage configuration, you can also set how to handle the problem when the storage usage is insufficient. In addition to the default wait, sendFailIfNoSpace and sendFailIfNoSpaceAfterTimeout are also supported.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/14353215T-9.jpg "title =" slide 29.JPG" alt = "183144942.jpg"/>

ActiveMQ supports JMX. The following is an example of JMX configuration in ActiveMQ. After startup, you can connect to ActiveMQ through the jconsole Java tool to monitor it.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1435322447-10.jpg "title =" slide 30.JPG" alt = "183207168.jpg"/>

For message persistence, messages are stored in the queue in the FIFO mode. Messages are queued only when the consumer's confirmation is received.

For topics with persistent subscribers, only one message is saved in the topic. Each persistent subscriber saves a pointer to the last received message. The message is deleted from the topic only when the message is confirmed by all persistent subscribers.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/143532E26-11.jpg "title =" slide 31.JPG" alt = "183231185.jpg"/>

The following describes four message storage mechanisms.

KahaDB is a message storage mechanism recommended by ActiveMQ. It is based on files and is the fastest message storage mechanism.

The implementation mechanism of KahaDB. First, all the message data is appended to the log file. The size of the log file is limited. If the limit is reached, a new file is created, if all messages in the log file have been sent, the file is deleted. The queue and topic are stored in the B-tree data structure, so that messages can be quickly queried. Messages in B-tree are actually stored as references to data in log files. Messages of the queue and topic are also stored in the cache to increase the access speed.

Like KahaDB, it is based on files, but unlike KahaDB, each queue has an independent index file, which is mostly used in scenarios with a large number of messages, but not applicable to scenarios with many queues.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/143532J27-12.jpg "title =" slide 32.JPG" alt = "183300181.jpg"/>

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1435325N8-13.jpg "title =" slide 33.JPG" alt = "183334198.jpg"/>

When connecting clients to servers or servers, ActiveMQ supports multiple connection protocols. The following are the protocols and instructions for use. TCP is the default network protocol used by ActiveMQ, STOMP is a message protocol for simple text. It is mainly used for multi-language support. In practice, we use this protocol when connecting PHP and Python clients to the server, VM is mainly used to access servers running in the same JVM.

When the client uses a vm to connect to the Message Server, such as vm: // brokerName, if the same JVM memory is in the message server instance named after the brokerName, it is connected to the instance. If it does not exist, create a message server instance named after the brokerName and connect to it.

The URI format used for connection is as follows. The first is a single URI, which indicates the connection address of a message server, and the second is the combination URI, which combines multiple Message Server addresses.

In the message server configuration, there are two types of connections:

Transportctor, used to configure the connection between the client and the server and provide the connection port to the client. ActiveMQ usually occupies port 61616 to provide tcp connections externally;

Networkconnector is used to configure the connection between the server and the server to implement the server network. The following describes the two server networks of ActiveMQ.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1435322611-14.jpg "title =" slide 34.JPG" alt = "183359271.jpg"/>

The first is static network.

If the server configuration in the network is known, you can use static to create a static network. For example, if a Message Server BrokerB exists in a known network, you can add the preceding configuration to the BrokerA configuration, when BrokerA is started, BrokerA creates a connection with BrokerB. When the producer sends the message to BrokerA and the consumer receives the message from BrokerB, BrokerA automatically forwards the message to BrokerB.

In this configuration, BrokerA-BrokerB connections are unidirectional, that is, messages can only be forwarded from BrokerA to BrokerB. If you need to configure the connection to two-way, you can set the duplex attribute to true. In this way, BrokerA and BrokerB can forward messages to and receive messages from the other party.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/143532A61-15.jpg "title =" slide 35.JPG" alt = "183426344.jpg"/>

The static network needs to know the service configurations and is not easy to expand later. The above problems can be solved by using a dynamic network. In a dynamic network, the preceding configurations are required for each Message Server. After the service is started, IP multicast is automatically used to find other message server instances in the network and create a connection.

650) this. width = 650; "src =" http://img1.51cto.com/attachment/201309/183456317.jpg "title =" slide 36.JPG" alt = "183456317.jpg"/>

When a client connects to the Message Server, you can either use a single URI to connect to a single server or use a combination URI to select one from multiple servers for connection.

In a combination URL, failover is a common client connection method. When failover is used, the client selects a random connection from multiple server addresses. When the connection fails, will try to connect to other servers.

If you only connect to one server, we recommend that you add a failover before the server address so that you can establish a reconnection mechanism to improve system robustness.

Discovery is similar to failover, but queries available servers from the dynamic network through multicast, and randomly selects a connection from it. When the connection fails, it tries to connect to other servers.

Similar to vm, when using peer connection, the server is automatically created in JVM. In addition, the connection between the server and the same group of servers in the network is also established.

The Application Scenario of peer is that the connection between the client and the server often fails, but the client can still work normally when the connection fails. With peer, the client can create a server in the local JVM and communicate with it. When the connection is normal with the remote server, the local server will communicate with the remote server.

Fanout can send messages to a static or dynamic network. Each server in the network receives messages.

This article is from the "Learning document" blog, please be sure to keep this source http://zephiruswt.blog.51cto.com/5193151/1303873