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

This article shares with you the content of the sample analysis of Network in ActiveMQ. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Start multiple Broker on one server

The steps are as follows (prepare for the cluster):

1: make a copy of the entire conf folder, such as conf2

2: modify the activemq.xml file in it

(1) the brokerName in it cannot be repeated with the original one

(2) the name of the file in which the data is stored must not be repeated, such as:

(3) the ports of all designed transportConnectors should be different from the previous ones.

3: modify jetty.xml, mainly to modify the port, such as:

The port must be different from the previous one

4: under bin, copy an activemq, such as activemq2

(1) modify the id of the program, which cannot be repeated with the previous one.

ACTIVEMQ_PIDFILE= "$ACTIVEMQ_DATA/activemq2-hostname.pid"

(2) modify the configuration file path

ACTIVEMQ_CONF= "$ACTIVEMQ_BASE/conf2"

(3) modify the port. There is a port of 61616 of tcp. If you want to change it to something different, it had better be the same as the port of ctp in activemq.xml.

(4) then it can be executed.

2. Static network link of ActiveMQ

What is ActiveMQ's networkConnector?

In some scenarios, multiple Broker of ActiveMQ are required to cluster, and the communication of Broker is involved for so long, which is called the networkConnector of ActiveMQ.

ActiveMQ's networkConnector is one-way by default, with one Broker sending messages on one side and another Broker receiving messages on the other side. This is the so-called "bridge". ActiveMQ also supports bi-directional linking. Create a bi-directional channel. For two Broker, you can not only send messages but also receive messages from the same channel, usually mapped as duplex connector, as follows:

The concept of "discovery"

In general, discovery is used to discover remote services, and clients usually want to discover all available brokers;. It is based on the existing network Broker to discover other available Brokers.

There are two ways to configure the link from Client to Broker, one way: Client connects to Broker through Statically configuration, and the other way: Client discovers Brokers through discovery agents through dynamically

Static networks

Static networkConnector is used to create a static configuration for multiple Broker in the network. This protocol is used for composite url, where a composite url includes multiple url addresses. The format is as follows:

Static: (uri1,uri2,uri3,...)? Key=value

1: the configuration example is as follows (activemq.xml-- comments out the persistenceFactory node):

The basic original schematic diagram of Static networkConnector:

In the figure above, the two Brokers are connected to the network through a static protocol. A Consumer is linked to an address of BrokerB, and when Producer sends a message at the same address on BrokerA, it is transferred to BrokerB. That is, BrokerA forwards the message to BrokerB.

Available properties for networkConnector configuration

1. Name: default is bridge

2. DynamicOnly: the default is false. If true, the corresponding network persistent subscription will be created only when the persistent subscription is activated. The default is to activate at startup

3. DecreaseNetworkConsumerPriority: the default is false. Set the consumer priority. If true, the consumer priority of the network is reduced to-5. If false, the default is 0, just like local consumers

4. NetworkTTL: default is 1, and the number of broker used for message and subscription consumption in the network

5. MessageTTL: the default is 1, and the number of broker used for messages in the network

6. ConsumerTTL: the default is 1, and the number of broker used for consumption in the network

7. ConduitSubscriptions: default true, whether to treat multiple consumer of the same broker as one

8. DynamicallyIncludedDestinations: the dynamic message address to be included is empty by default, similar to excludedDestinations, such as

9. StaticallyIncludedDestinations: the static message address to be included, which is empty by default. Similar to excludedDestinations, such as:

10. ExcludedDestinations: the default is empty, and the address to be excluded is specified. The example is as follows:

11. Duplex: default false, which sets whether two-way communication is allowed.

12. PrefetchSize: default is 1000. The maximum number of unacknowledged messages held must be greater than 0, because online consumers cannot poll messages themselves.

13. SuppressDuplicateQueueSubscriptions: default false. If true, duplicate subscription relationships are blocked as soon as they are generated.

14. BridgeTempDestinations: default true, whether to broadcast advisory messages to create a temporary destination

15. AlwaysSyncSend: default false. If true, non-persistent messages will also be sent to the remote broker using request/reply instead of oneway.

16. StaticBridge: default false. If true, only destination configured in staticallyIncludedDestinations can be processed.

III. "lost" news

There is a scenario where broker1 and broker2 connect through networkConnector, and some consumers connect to broker1, consuming messages on broker2. The message is first consumed from the broke2 by broker1 and then forwarded to these consumers. Unfortunately, broker1 restarted when some messages were forwarded, and these consumers found that the broker1 connection failed and connected to broker2 through failover, but another part of the messages they had not yet consumed were distributed to broker1 by broker2. These messages seem to disappear unless consumers reconnect to broker1 to spend.

Since version 5. 6, the new option replayWhenNoConsumers has been added to destinationPolicy. This option allows messages that need to be forwarded on the broker1 but no consumers to flow back to its original broker. At the same time, set enableAudit to false to prevent messages from being returned and not being distributed as duplicate messages. The example is as follows:

IV. Fault-tolerant connections

Failover Protocol

Previous Client configurations were linked to the specified broker. But what if the link to Broker fails? At this point, Client has two options: either die immediately or connect to another broker.

The Failover protocol implements the logic of automatic relink. There are two ways to provide a stable brokers list for Client links.

First: provide a list of available Brokers for static

Second: provide an available Brokers found by dynamic

Default mode of Failover Protocol

Failover: (uri1,...,uriN)? key=value or failover:uri1,...,uriN

& default configuration of Failover Protocol

By default, this protocol is used to randomly select a link to link, and if the link fails, it will be linked to another Broker. The default configuration defines delayed relink, which means that the transport will automatically relink the available broker after 10 seconds. All relink parameters can be configured according to the needs of the application.

Example of the use of Failover Protocol, in the client program

ConnectionFactory connectionFactory = new ActiveMQConnectionFactory ("failover: (tcp://localhost:61616,tcp://localhost:61617)? randomize=false")

Configuration parameters available for Failover Protocol:

1. InitialReconnectDelay: the waiting time (milliseconds) before the first attempt to reconnect defaults to 10

2. MaxReconnectDelay: the longest reconnection interval (milliseconds). Default is 30000.

3. UseExponentialBackOff: whether the interval between reconnection increases exponentially. Default is true.

4. BackOffMultiplier: increment multiples. Default is 2.0.

5. MaxReconnectAttempts: default-1 | 0, starting from version 5.6.The default value is-1, which means there is no limit on the number of retries. 0 means never retry (only one connection is attempted and not reconnected). Before version 5.6, 0 is the default value, which means unlimited number of retries. A number greater than 0 represents the maximum number of retries.

6. StartupMaxReconnectAttempts: the maximum number of reconnections during initialization. Once connected, the configuration of maxReconnectAttempts will be used. Default is 0

7. Randomize: use random connections to achieve load balancing. Default is true.

8. Backup: initialize an unused connection in advance for quick failover. Default is false.

9. Timeout: sets the timeout for sending operations (milliseconds). Default is-1.

10. TrackMessages: set whether to cache messages that have not yet been delivered [in case of failure]. Once the broker reconnects successfully, the cached messages will be flushed to the newly connected proxy, so that the messages can be sent sequentially before and after the broker switch. The default is false.

11. MaxCacheSize: the maximum cache byte when trackMessages is enabled. Default is 128-1024 bytes.

12. UpdateURIsSupported: set whether broker rui can be modified dynamically (since version 5.4). Default is true.

5. Dynamic network connection (pure theory)

Multicast protocol multicast

ActiveMQ uses the Multicast protocol to connect one Service to the Service of other Broker. IP multicast is a technology that is used to transmit data to other groups of receivers in a network.

The traditional concept of IP multicast is called group address. The group address is an ip address with an ip address between 224.0.0.0 and 239.255.255.255. ActiveMQ broker uses the multicast protocol to establish a network connection between the service and the remote broker service.

Basic format configuration

Multicast://ip address:port?transportOptions

1. Group: indicates a unique group name. The default value is default.

2. MinmumWireFormatVersion: the smallest wireformat version allowed. The default is 0.

3. Trace: whether to track and record logs. Default is false.

4. UseLocalHost: indicates whether the name of the local machine is localhost. Default is true.

5. DatagramSize: specific data size. Default is 41024.

6. TimeToLive: the declared periodic value of the message. The default value is-1.

7. LoopBackMode: whether to enable loopback mode. Default is false

8. WireFormat: named after wireFormat by default

9. The wireFormat.: prefix is wireFormat

Configuration example

1: default configuration, unreliable multicast by default, packets may be lost

Multicast://default

2: specific ip and port

Multicast://224.1.2.3:6255

3: specific ip and port and group name

Multicast://224.1.2.3:6255?group=mygroupname

The configuration format for ActiveMQ to use the multicast protocol is as follows:

Description:

1the default in "multicast://default" is the default ip of activemq, which looks for addresses dynamically by default.

2: "discoveryUri" means to pass it in transport using the address of multicast's default.

3: "uri" refers to finding available addresses dynamically.

4: how to prevent automatic address search?

(1) remove the transport named openwire and remove discoveryUri= "multicast:

/ / default ". The transport connection configures broker's tcp multipoint connection with the default name openwire, which will allow other broker to automatically discover and connect to available broker.

(2) the networkConnector named "default-nc" can be commented out or deleted.

ActiveMQ default networkConnector the default name for multicast protocol-based connections is default-nc and automatically discovers other broker. To stop this behavior, simply log out or delete the default-nc network connection.

(3) make the name of brokerName unique, and you can uniquely identify the instance of Broker. The default is localhost.

Multicast protocol and ordinary tcp protocol

They are similar, except that multicast can automatically discover other broker, instead of using static feature list brokers. Using multicast protocol to add and delete ip frequently in the network will not have an impact.

Multicast protocol

Benefits: the ability to adapt to dynamically changing addresses.

Disadvantages: automatically connecting addresses will consume network resources excessively

Discovery protocol

Discovery is defined on the functionality of the multicast protocol. The function is similar to the Failover function. It will dynamically discover the connection of the broker of the multicast protocol and randomly connect one of the broker.

The basic configuration is as follows:

Discovery: (discoveryAgentURI)? transportOptions

1. ReconnectDelay: wait time for re-addressing. Default is 10.

2. InitialReconnectDelay: initialize the wait time for re-addressing. The default is 10.

3. MaxReconnectDelay: maximum addressing wait time. Default is 30000.

4. UseExponentialBackOff: whether to try BackOff reconnection. The default is true.

5. BackOffMultiplier: the number of Backoff attempts. Default is 2.

6. MaxReconnectAttempts: if there is an exception, the maximum number of reconnections. Default is 0.

7. Group: the unique address of the group. The default is default.

Example:

Discovery: (multicast://default)? initialReconnectDelay=100

Configuration example of Discovery protocol

Peer protocol

ActiveMQ provides peer transport connector to make it easier to embed in broker networks. It creates a P2P network connection that is superior to the vm connection. The default format is as follows:

Peer://peergroup/brokerName?Key=value

Basic use of Peer protocol

When we enable the peer protocol, the application will automatically start the embedded broker and automatically configure other broker to establish a connection, as long as there must be a group. The configuration is as follows:

Peer://groupa/broker1?Persistent=false

In addition, producers and consumers each connect to the broker embedded in their own applications and access data to each other in the same group name locally.

The basic principles of Peer protocol

When the local machine is disconnected, the local client access to the local brokerA will still be normal.

Send messages to the local brokerA when the network is off, and then when the network connection is normal, all messages will be resent and connected to the brokerB.

Fanout protocol

Fanout protocol connects to multiple broker at the same time. The default format is as follows:

Fanout: (fanoutURI)? key=value

Example: fanout: (static: (tcp://host1:61616,tcp://host2:61616))

Indicates that client will attempt to connect to the three URI defined in the two static lists

The configuration parameters of Fanout protocol are as follows:

1. InitialReconnectDelay: the waiting time for reconnection. Default is 10.

2. MaxReconnectDelay: the maximum waiting time for reconnection. Default is 30000.

3. UseExponentialBackOff: whether to try BackOff reconnection. The default is true.

4. BackOffMultiplier: the number of Backoff attempts. Default is 2.

5. MaxReconnectAttempts: if there is an exception, the maximum number of reconnections. Default is 0.

6. FanOutQueues: whether to convert topic messages into queue messages. Default is false.

7. The minimum number of minAckCount:Broker connections. Default is 2.

Example configuration:

Fanout: (static: (tcp://localhost:61616,tcp://remotehost:61616)?

InitialReconnectDelay=100

Note:

ActiveMQ does not recommend Consumer to use the fanout protocol. When Provider sends messages to multiple broker, the test Consumer may receive duplicate messages.

Thank you for reading! This is the end of this article on "sample Analysis of Network in ActiveMQ". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

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.