4.5 网络连接器-Network connectors

A network of brokers creates a cluster composed of multiple ActiveMQ instances that

are interconnected to meet more advanced messaging scenarios. Various topologies

for broker networks, their purpose, and their configuration details are explained in

detail in chapter 10. The previous section discussed transport connectors that provide

client-to-broker communications, whereas this section will discuss network connectors

that provide broker-to-broker communications.

Network connectors are channels that are configured between brokers so that

those brokers can communicate with one another. A network connector is a

unidirectional channel by default. A given broker communicates in one direction by

only forwarding messages it receives to the brokers on the other side of the connection.

This setup is commonly referred to as a forwarding bridge. In some situations, you

may want to create a bidirectional communication channel between brokers—a channel

that communicates not only outward to the brokers on the other side of the connection,

but also receives messages from other brokers on that same channel.

ActiveMQ supports this kind of bidirectional connector, which is usually referred to as

a duplex connector. Figure 4.5 shows one example of a network of brokers that contains

both a forwarding bridge and duplex connectors.

ActiveMQ支持的这种双向连接器,通常也被称为双重连接器.图4.5是一个包含单向连接桥和双向连接器的

Network connectors are configured through the ActiveMQ XML configuration file in a

fashion similar to the configuration of transport connectors. Let’s take a look at an

example configuration:

<networkConnectors>

<networkConnector name=”default-nc” uri=”multicast://default”/>

</networkConnectors>

<networkConnectors>

<networkConnector name=”default-nc” uri=”multicast://default”/>

</networkConnectors>

As you can see, networks of brokers are configured using the <networkConnectors>

element. This element contains the configuration for one or more connectors using

the <networkConnector> element. As was the case with transport connectors, the

mandatory attributes for the <networkConnector> element are the name and the uri.

All other attributes are optional and are used to configure additional features on the

connector, as you’ll see in a moment.

<networkConnector>子元素配置一个或多个网络连接器.和配置传输连接器一样,配置<networkConnector>

In the rest of this chapter, various ActiveMQ protocols and techniques that are

used to configure and connect to a network of brokers will be presented and discussed.

But before we dive in, there’s one more important ActiveMQ concept we

should explain known as discovery. In general, discovery is a process of detecting

remote broker services. Clients usually want to discover all available brokers. Brokers,

on the other hand, usually want to find other available brokers so they can establish a

network of brokers.

When you want to configure a network of brokers, the first obvious question is, do

you know the exact network address of each broker in the network? If the answer is

yes, then you can proceed configuring your network statically and also connect your

clients to predefined broker URIs. This situation is more often seen in production

environments where you want to have total control of all resources. Section 4.5.1

explains how you can set up and use static networks. It starts with explaining the static

protocol used to connect multiple brokers together. Then, we’ll explain a failover protocol

that allows clients to connect to one of the brokers in the network and also utilize

reconnection logic.

In case clients and brokers don’t know each other’s network addresses, they must

use some kind of a discovery mechanism to dynamically locate the available brokers.

This kind of setup is more often found in development environments, as it’s much

easier to set up and maintain. Discovery agents and the protocols they use are

explained in section 4.5.2. You’ll learn how IP multicast is used by brokers to advertise

their services and locate other available brokers, using the multicast connector. Also,

we’ll see how clients use the multicast connector to discover brokers using a discovery

connector.

We’ll also dive into the peer connector, which makes creating a network of embedded

brokers a very simple task. Finally, we’ll see how the fanout connector enables clients

to send messages to multiple brokers. Let’s begin with static networks.

4.5.1 Static networks

4.5.1 静态网络

The first approach to configuring and connecting to a network of brokers is through

the use of statically configured URIs—configuring a list of broker URIs available for

connection. The only prerequisite is that you know the addresses of all the brokers you

want to use. Once you have these URIs, you need to know how to use them in a configuration.

So let’s look at the connector available to create a static networks of brokers.

STATIC CONNECTOR

The static network connector is used to create a static configuration of multiple brokers

in a network. This protocol uses a composite URI—a URI that contains other URIs. A

composite URI consists of multiple broker addresses or URIs that are on the other end

of the network connection.

Here’s the URI syntax for the static protocol:

static:(uri1,uri2,uri3,…)?key=value

You can find the complete reference for this transport at the ActiveMQ website

(http://mng.bz/r74v).

Now take a look at the following configuration example:

<networkConnectors>

<networkConnector name=”local network” uri=”static://(tcp://remotehost1:61616,tcp://remotehost2:61616)”/>

</networkConnectors>

Assuming that this configuration is for the broker on the localhost and that brokers

on hosts remotehost1 and remotehost2 are up and running, you’ll notice the following

messages when you start the local broker:

(译注:远程的主机上必须启动了ActiveMQ代理,否则连接不能成功建立)

INFO DiscoveryNetworkConnector – Establishing network connection between from vm://localhost to tcp://remotehost1:61616

INFO TransportConnector – Connector vm://localhost Started

INFO DiscoveryNetworkConnector – Establishing network connection between from vm://localhost to tcp://host2:61616

INFO DemandForwardingBridge – Network connection between vm://localhost#0 and tcp://remotehost1:61616 has been established.

INFO DemandForwardingBridge – Network connection between vm://localhost#2 and tcp://remotehost2:61616 has been established.

The output indicates that the broker on the localhost has successfully configured a

forwarding bridge with two other brokers running on two remote hosts. In other words,

messages sent to the local broker will be forwarded to brokers running on

remotehost1 and remotehost2, but only if there’s demand for those messages from a

consumer.

The best way to understand this is to walk through the use of static networks using

the stock portfolio example with a network of brokers. Figure 4.6 provides a perspective

of the broker topology used in this example.

In the diagram, the two brokers are networked. The brokers utilize a network connector

with a URI using the static protocol. A consumer is attached to a destination on

BrokerB, which creates demand for messages across the network connector. When the

producer sends messages to the same destination on BrokerA, they’ll be forwarded to

the broker where there’s demand. In this case, BrokerA forwards messages to BrokerB.

The following example will walk through this basic use case.

To make this example work, first we need to start these two networked brokers.

<broker xmlns=”http://activemq.apache.org/schema/core” brokerName=”BrokerB” dataDirectory=”${activemq.base}/data”> <transportConnectors> <transportConnector name=”openwire” uri=”tcp://localhost:61617″ /> </transportConnectors> </broker> This simple configuration starts a broker that listens on port 61617. We can start this broker with the following command: 这个简单的配置启动一个代理监听61617端口.我们可以使用下面的命令启动这个代理:${ACTIVEMQ_HOME}/bin/activemq console xbean:src/main/resources/org/apache/activemq/book/ch4/brokerA.xml

(译注:window的DOS使用的命令:%ACTIVEMQ_HOME%/bin/activemq xbean:src/main/resources/org/apache/activemq/book/ch4/brokerA.xml)

(注意:使用apache-activemq-5.8.0版本的ActiveMQ测试时,brokerA.xml文件需要修改,参考默认的activemq.xml修改即可,

<transportConnectors>

<transportConnector name=”openwire” uri=”tcp://localhost:61616″ />

</transportConnectors>

<networkConnectors>

<networkConnector uri=”static:(tcp://localhost:61617)” />

</networkConnectors>

</broker>

Besides the transport connector listening on port 61616, it defines a network connector

that connects to BrokerB. In a separate console window, you can start this broker

like this:

${ACTIVEMQ_HOME}/bin/activemq console \xbean:src/main/resources/org/apache/activemq/book/ch4/brokerB.xml (译注:window的DOS使用的命令:%ACTIVEMQ_HOME%/bin/activemq xbean:src/main/resources/org/apache/activemq/book/ch4/brokerB.xml) (注意:使用apache-activemq-5.8.0版本的ActiveMQ测试时,brokerB.xml文件需要修改,参考默认的activemq.xml修改即可, 主要改了beans元素里面的主题schema部分,复制即可.另外改了dataDirectory=”${activemq.data}”这个)

Now that we have both brokers up and running, let’s run the stock portfolio example.

First we’ll start our publisher and connect it to BrokerA:

$mvn exec:java -Dexec.mainClass=org.apache.activemq.book.ch4.Publisher -Dexec.args=”tcp://localhost:61616 CSCO ORCL” Sending: {price=65.713356601409, stock=JAVA, offer=65.779069958011, up=true} on destination: topic://STOCKS.JAVA Sending: {price=66.071605671946, stock=JAVA, offer=66.137677277617, up=true} on destination: topic://STOCKS.JAVA Sending: {price=65.929035001620, stock=JAVA, offer=65.994964036622, up=false} on destination: topic://STOCKS.JAVA This is practically the same command was used with the earlier TCP connector example. 这个命令几乎和前面使用TCP连接器时的命令一样. Now start the consumer and connect it to BrokerB: 下面使用下面的命令运行consumer并连接到BrokerB:$ mvn exec:java -Dexec.mainClass=org.apache.activemq.book.ch4.Consumer -Dexec.args=”tcp://localhost:61617 CSCO ORCL”

ORCL 65.71 65.78 up

ORCL 66.07 66.14 up

ORCL 65.93 65.99 down

CSCO 23.30 23.33 up

Using this setup, messages are published to BrokerA. These messages are then forwarded

to BrokerB, where they’re received by the consumer. The overall functionality

of this example hasn’t been changed and both the publisher and the consumer

behave the same as the previous single broker example. The only difference is that the

publisher and the consumer are now connecting to different brokers that are networked

using the static protocol.

From this simple example you can conclude that this particular configuration can

advantages of communicating with the local broker instead of a remote one.

EXAMPLE USE OF THE STATIC PROTOCOL

Configuring broker networks can be difficult depending on the situation. Use of the

static protocol allows for an explicit notation that a network should exist. Consider a

situation where clients in remote offices are connecting to a broker in the home

office. Depending on the number of clients in each remote office, you may wind up

with far too many wide area network connections into the home office. This can cause

an unnecessary burden on the network. To minimize connections, you may want to

place a broker in each remote office and allow a static network connection between

the remote office broker and the home office broker. Not only will this minimize the

number of network connections between the remote offices and the home office, but

it’ll allow the client applications in the remote offices to operate more efficiently. The

removal of the long haul connection over the wide area network means less latency

and therefore less waiting for the client application.

FAILOVER PROTOCOL

In all the examples so far, the clients have been configured to connect to only one

specific broker. But what should you do in case you can’t connect to the desired broker

or your connection fails at the later stage? Your clients have two options: either

they’ll die gracefully or try to connect to the same or some other broker and resume

their work. As you can probably guess, the stock portfolio example runs using the

protocols described thus far and aren’t immune to network problems and unavailable

brokers. That’s where protocols such as failover come in to implement automatic

reconnection. Similar to the case with the network connectors, there are two ways to

provide a list of suitable brokers to which the client can connect. In the first case, you

provide a static list of available brokers. This is the approach used by the failover transport

connector. In the second case, dynamic discovery of the available brokers is used.

This will be explained later in the chapter. This section will examine the failover

transport connector.

The URI syntax for the failover connector is similar to the previous static network

connector URI. There are actually two available forms to the failover URI:

failover:(uri1,…,uriN)?key=value

failover:uri1,…,uriN

The complete reference of this protocol can be found at the ActiveMQ website (http:/

/mng.bz/u58s).

By default, this protocol uses a random algorithm to choose one of the underlying

connectors. If the connection fails (both on startup or at a later stage), the transport

will pick another URI and try to make a connection. A default configuration also

implements reconnection delay logic, meaning that the transport will start with a 10ms

delay for the first reconnection attempt and double this time for any subsequent

attempt up to 30000ms. Also, the reconnection logic will try to reconnect indefinitely.

Of course, all reconnection parameters can be reconfigured according to your needs

using the appropriate transport options.

Recall the theoretical static network of brokers that was defined in the previous

section. In that example, all messages sent to the local broker could be forwarded to

the brokers located on remotehost1 and remotehost2. Because all messages could be

sent to both of these brokers, those messages can be consumed from either broker.

The same is true here. The only difference is that the failover transport will automatically

attempt a reconnect in the event of a broker failover. To experience the use of

this transport, run the stock portfolio consumer and configure it to connect to the

brokers using the failover connector:

$mvn exec:java -Dexec.mainClass=org.apache.activemq.book.ch4.Consumer -Dexec.args=”failover:(tcp://remotehost1:61616,tcp://remotehost2:61616) CSCO ORCL” The beauty of this solution is that it requires no changes to the application in order to add support for automatic reconnection in the event of a broker failure. Now let’s see the failover connector at work. Imagine that the random algorithm in the failover transport has chosen to connect the consumer to the broker on host1. You can expect that the consumer will print the following log message during the startup: 这种解决方案的妙处在于,当代理失效时,应用程序不需要做任何的修改就可以拥有这种自动重连机制. 下面让我们看看失效转移连接器如何工作的.想象一下失效转移连接器中使用随机算法选择了host1然后 consumer连接到连接器.可以预测,在启动时consumer会发生异常,并打印以下信息: org.apache.activemq.transport.failover.FailoverTransport$1 iterate INFO: Successfully reconnected to tcp://host1:61616

As we already said, all messages sent by the publisher to the local broker will be forwarded

to the broker on host1 and received by the consumer. Now try to simulate a

broker failure by shutting down the broker on host1. The consumer will print the following

log message:

org.apache.activemq.transport.failover.FailoverTransport handleTransportFailure

WARNING: Transport failed,attempting to automatically reconnect due to: java.io.EOFException java.io.EOFException

at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:268)

at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:184)

at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:172)

org.apache.activemq.transport.failover.FailoverTransport$1 iterate INFO: Successfully reconnected to tcp://host2:61616 Notice the initial exception noting the failure, followed by the log message about reconnecting to another broker. This means that the consumer has successfully connected to the other broker and you can see that it resumed its normal operation without any assistance. 注意到初始的异常提示了连接失败,紧接着是关于重新连接到另外代理的日志信息.这意味着consumer 已经成功的连接到了其他的代理.你可以看到consumer无需任何协助即可恢复其正常的功能. EXAMPLE USE OF THE FAILOVER PROTOCOL 失效恢复协议实例 Due to its reconnection capabilities, it’s highly advisable that you use the failover protocol for all clients, even if a client will only be connecting to a single broker. For example, the following URI will try to reestablish a connection to the same broker in the event that the broker shuts down for any reason: 鉴于这种自动重连功能,强烈推荐你在每个客户端都使用这种失效转移连接器.即使有的客户端仅仅连接到 单一的代理也推荐使用这种失效转移连接器.比如,使用下面的uri,无论何种情况导致代理关闭后,客户端都 将尝试重新连接到指定的代理: failover:(tcp://localhost:61616) The advantage of this is that clients don’t need to be manually restarted in the case of a broker failure (or maintenance, and so forth). As soon as the broker becomes available again the client will automatically reconnect. This means far more robustness for your applications by simply utilizing a feature of ActiveMQ. The failover transport connector plays an important role in achieving advanced functionalities such as high availability and load balancing as will be explained in chapter 12. 这种机制的优势在于,当代理失效后(或者维护后,等等),客户端不必手动重启.一旦代理恢复可用,客户端能自动重连. 这就意味着使用 ActiveMQ的这一特性使得你的应用程序变得更加健壮. 正如将在第12章中讨论的那样,失效转移连接器在诸如高可用性和负载平衡等高级功能的实现中起到了举足轻重的作用. 4.5.2 Dynamic networks 4.5.2 动态网络 Thus far we’ve seen how to set up broker networks and connect to them by explicitly specifying broker URIs (both transport and network connectors). As you’ll see in this section, ActiveMQ implements several mechanisms that can be used by brokers and clients to find each other and establish necessary connections. 至此,我们已经看到了如何设置代理的网络以及通过明确指定的URI(包括传输连接和网络连接)来连接到代理的方法. 本节中,你将看到ActiveMQ实现的几种机制,通过这些机制代理和客户端可以发现彼此并建立必要的连接. MULTICAST CONNECTOR 多点传送连接器 IP multicast is a network technique used for easy transmission of data from one source to a group of interested receivers (one-to-many communications) over an IP network. One of the fundamental concepts of IP multicast is the so-called group address. The group address is an IP address in the range of 224.0.0.0 to 239.255.255.255 used by both sources and receivers. Sources use this address as a destination for their data, whereas receivers use it to express their interest in data from that group. IP地址多点传送技术用于简化数据传输,在一个IP网络中,将一个数据源的数据群发到一组感兴趣的接收方 (一对多通信).IP地址多点传送的一个基础概念是所谓的群组地址.群组地址是一组发送发和接收方都可以使用的 IP地址,其范围从224.0.0.0 到 239.255.255.255.消息发送发用将这些IP地址用作它们发送数据的目的地,而 接收方用其作为群组中它们感兴趣的数据源. When IP multicast is configured, ActiveMQ brokers use the multicast protocol to advertise their services and locate the services of other brokers for the purpose of creating networks of brokers. Clients, on the other hand, use multicast to locate brokers and establish a connection with them. This section discusses how brokers use multicast; the use of multicast by a client will be discussed later. 当配置了IP多点传送后,ActiveMQ的代理可以通过多点传送协议广播自己的服务,并且定位其他提供服务的代理 以便建立一个代理网络.而客户端可以使用多点传送技术来定位代理并建立到代理的连接.本小节将讨论代理 如何使用多址传送.稍后将讨论客户端如何使用多址传送. The URI syntax for the multicast protocol is as follows: 多址传送协议的URI语法如下: multicast://ipadaddress:port?key=value This is no different than the previous URIs with the exception of the scheme portion. Here’s a snippet from the default ActiveMQ configuration that makes use of multicast: 这和前面介绍提到的URI语法基本一样,除了主题(scheme)部分有些不同.下面是ActiveMQ默认的使用多点传送的配置片段: <broker xmlns=”http://activemq.apache.org/schema/core” brokerName=”multicast” dataDirectory=”${activemq.base}/data”>

<networkConnectors>

<networkConnector name=”default-nc” uri=”multicast://default”/>

</networkConnectors>

<transportConnectors>

<transportConnector name=”openwire” uri=”tcp://localhost:61616″ discoveryUri=”multicast://default”/>

</transportConnectors>

</broker>

In the example, the group name default is used instead of a specific IP address. There

are two important things achieved with this configuration snippet. First, the transport

connector’s discoveryUri attribute is used to advertise this transport’s URI on the

default group. All clients interested in finding an available broker would use this connector.

This will be demonstrated in the following section.

Next, the uri attribute of the network connector is used to search for available

brokers and to create a network with them. In this case, the broker acts like a client

and uses multicast for lookup purposes. You can find a complete reference of this protocol

at the ActiveMQ website (http://mng.bz/14yJ).

Now that you know how to configure discovery on the broker side, I’m sure you’re

wondering where you might use this protocol.

EXAMPLE USE OF THE MULTICAST PROTOCOL

The multicast protocol is somewhat different from the TCP protocol. The difference is

the automatic discovery of other brokers instead of using a static list of brokers.

Preventing automatic broker discovery

When developing in a team environment it’s possible (and quite probable) that two

or more ActiveMQ instances will automatically connect to one another and begin consuming

one another’s messages. Here are some recommendations for preventing this situation from occurring:

1 Remove the discoveryUri portion of the openwire transport connector—The transport

connector whose name is openwire is configured by default to advertise the

broker’s TCP transport using multicast. This allows other brokers to automatically

discover it and connect to it if necessary.

1.移除openwire transport connector的discoveryUri属性–默认配置中,名称为openwire的传输连接器

Here’s the OpenWire transport connector definition from the conf/activemq.xml

configuration file:

<transportConnector name=”openwire” uri=”tcp://localhost:61616″ discoveryUri=”multicast://default”/>

To stop the broker from advertising the TCP transport URI via multicast, change

the definition to remove the discoveryUri attribute so it looks like this:

<transportConnector name=”openwire” uri=”tcp://localhost:61616″ />

2 Comment out/remove the default-nc network connector—The network connector

named default-nc utilizes the multicast transport to automatically and dynamically

discover other brokers. To stop this behavior, comment out/remove the default-nc

network connector so that it won’t automatically discover other brokers.

2.注释掉/移除名称为default-nc的网络连接器–网络连接器default-nc利用多点传送可以动态的自动

Here’s the default-nc network connector definition from the conf/activemq.xml

configuration file:

<networkConnector name=”default-nc” uri=”multicast://default”/>

To disable this network connector, comment it out so it looks like this:

<!–networkConnector name=”default-nc” uri=”multicast://default”/–>

3 Give the broker a unique name—The default configuration for ActiveMQ in the

conf/activemq.xml file provides a broker name of localhost as shown:

3.给代理起一个唯一的名称–ActiveMQ的默认配置文件conf/activemq.xml用下面的代码配置了一个

<broker xmlns=”http://acti vemq.apache.org/schema/core” brokerName=”localhost” dataDirectory=”${activemq.base}/data”> In order to uniquely identify your broker instance, change the brokerName attribute from localhost to something unique such as in the following example: 为了使代理实例标识唯一,修改brokerName属性,将属性值从localhost改成其他某个唯一的值,比如可以按下面的代码修改: <broker xmlns=”http://activemq.apache.org/schema/core” brokerName=”broker1234″ dataDirectory=”${activemq.base}/data”>

This is especially handy when searching through log files to see which brokers are

taking certain actions.

Use of the multicast protocol is common where brokers are added and removed frequently,

and in cases where brokers may have their IP addresses changed frequently. In these

cases, instead of reconfiguring each broker manually for every change, it’s often easier

to utilize a discovery protocol.

One disadvantage to using the multicast protocol is that discovery is automatic. If

there are brokers that you don’t want to be automatically added to a given group, you

must be careful in setting up the initial configuration of the broker network. Careful

segmentation of broker networks is important, as you don’t want messages to wind up

in a broker network where they don’t belong. Another disadvantage of the multicast

protocol is that it can be excessively chatty on the network. For this reason, many network

before taking the time to configure a network using the multicast protocol.

As IP multicast can be used for discovery on the broker side, there’s a similar discovery

protocol for the client side.

IP多点传送用于代理端的自动侦测,同样在客户端也有类似自动侦测协议.

DISCOVERY PROTOCOL

The discovery transport connector is on the client side of the ActiveMQ multicast functionality.

This protocol is basically the same as the failover protocol in its behavior.

The only difference is that it’ll use multicast to discover available brokers and randomly

choose one to connect to.

ActiveMQ提供的自动侦测功能中,自动侦测连接器是在客户端一侧.这种协议大体上和失效转移协议的行为类似.

The syntax of this protocol is

discovery:(discoveryAgentURI)?key=value

Its complete reference could be found at the ActiveMQ website (http://mng.bz/96wI).

Using the multicast broker configuration explained earlier, you can run the broker

with the following command:

${ACTIVEMQ_HOME}/bin/activemq console xbean:src/main/resources/org/apache/activemq/book/ch4/activemq-multicast.xml (window下的命令为:%ACTIVEMQ_HOME%/bin/activemq xbean:src/main/resources/org/apache/activemq/book/ch4/activemq-multicast.xml) Once the broker is started, run the stock portfolio publisher with the following command: 启动代理后,可以使用下面的命令运行stock portfolio例子中的publisher:$ mvn -e exec:java -Dexec.mainClass=org.apache.activemq.book.ch4.Publisher -Dexec.args=”discovery:(multicast://default) CSCO ORCL”

You’ll notice the following log messages at the application startup:

Jun 18, 2008 2:13:18 PM org.apache.activemq.transport.discovery.DiscoveryTransport onServiceAdd

INFO: Adding new broker connection URL: tcp://localhost:61616  Jun 18, 2008 2:13:19 PM org.apache.activemq.transport.failover.FailoverTransport doReconnect

INFO: Successfully connected to tcp://localhost:61616

Sending: {price=65.713356601409, stock=JAVA, offer=65.779069958011, up=true} on destination: topic://STOCKS.JAVA

Sending: {price=66.071605671946, stock=JAVA, offer=66.137677277617, up=true} on destination: topic://STOCKS.JAVA

Sending: {price=65.929035001620, stock=JAVA, offer=65.994964036622, up=false} on destination: topic://STOCKS.JAVA

These messages tell you that the publisher client has successfully used multicast to discover

and connect to the local broker.

PEER PROTOCOL

As we’ve seen before, networks of brokers and embedded brokers are useful concepts

that allow you to fit brokers to your infrastructure needs. Of course, it’s theoretically

possible to create networks of embedded brokers, but this would be quite cumbersome

to configure manually. This is why ActiveMQ provides the peer transport connector,

as it allows you to more easily network embedded brokers. The peer connector is a

utility transport that is a superset of a VM connector that creates a peer-to-peer network

of embedded brokers.

The URI syntax of this protocol is as follows:

peer://peergroup/brokerName?key=value

You can find its complete reference at the ActiveMQ website (http://mng.bz/bIaH).

When started with the peer protocol URI, the application will automatically start an

embedded broker (just as was the case with the VM protocol), but will also configure

the broker to establish network connections to other brokers in the local network with

the same group name.

Let’s walk through a demonstration of this using the stock portfolio example with

the peer protocol. In this case, both the publisher and the consumer will use their

own embedded brokers that will be networked automatically. Figure 4.7 provides a

better perspective of this solution.

Advise the stock portfolio publisher to create its own embedded broker using

group1 like this:

group1:

$mvn -e exec:java -Dexec.mainClass=org.apache.activemq.book.ch4.Publisher -Dexec.args=”peer://group1 CSCO ORCL” Sending: {price=65.713356601409, stock=JAVA, offer=65.779069958011, up=true} on destination: topic://STOCKS.JAVA Sending: {price=66.071605671946, stock=JAVA, offer=66.137677277617, up=true} on destination: topic://STOCKS.JAVA Sending: {price=65.929035001620, stock=JAVA, offer=65.994964036622, up=false}on destination: topic://STOCKS.JAVA Also advise the stock portfolio consumer to create its own embedded broker using group1 like this: 同样,使用下面的命令使得stock portfolio中的consumer创建它自己的代理,并使用群组名称group1:$ mvn -e exec:java -Dexec.mainClass=org.apache.activemq.book.ch4.Consumer -Dexec.args=”peer://group1 CSCO ORCL”

ORCL 65.71 65.78 up

ORCL 66.07 66.14 up

ORCL 65.93 65.99 down

CSCO 23.30 23.33 up

The two commands start two embedded brokers (one for each application) and create

a peer-to-peer broker network named group1 between these two brokers. All messages

sent to one broker will be available in the other broker as well as any other

brokers that might join group1. Note that the overall system operates as if these two

applications were using the same centralized broker.

EXAMPLE USE OF THE PEER PROTOCOL

Consider an application that resides on the laptop of a field sales representative who

often disconnects from the company network but still needs the application to run

successfully in a disconnected mode. This is a common scenario where the client

application needs to continue working regardless of whether the network is available.

This is a case where the peer protocol can be utilized for an embedded broker to

allow the application on the laptop to keep running successfully. In reality, while in

disconnected mode, the application is simply sending messages to the local broker,

where they’re queued up to be sent at a later time when the network is available again.

The sales rep can still log client calls, visits, and so on while the laptop is disconnected

from the network. When the laptop is again connected to the network, all of the

queued messages will be sent along based on the demand from consuming clients.

FANOUT CONNECTOR

FANOUT连接器

Fanout is another utility connector used by clients to simultaneously connect to multiple

brokers and replicate operations to those brokers. The URI syntax of this protocol

is as follows:

Fanout是一种连接器群组,用于使得客户端可以同时连接到多个代理并对这些代理进行相同的操作.

Fanout协议的URI语法如下:

fanout:(fanoutURI)?key=value

You can find its complete reference at the ActiveMQ website (http://mng.bz/J7i0).

The fanoutURI can utilize either a static URI or a multicast URI. Consider the following

example:

fanoutURI值可以使用静态的URI或者多点传送URI.参考下面的示例:

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

In figure 4.8, the client will try to connect to three brokers statically defined using the

static protocol

The same effect could be accomplished by simply using the following URI:

fanout:(multicast://default)

This assumes that the brokers are configured to use multicast to advertise their transport connectors.

By default, the fanout protocol will wait until it connects to at least two brokers and won’t replicate

commands to queues (only topics). Both of these features are, of course, configurable with

appropriate transport options.Finally, there are a couple of things you should

be aware of if you plan to use the fanout protocol.First of all, it’s not recommended for consuming

messages. Its only purpose is to produce messagesto multiple brokers. Also, if the brokers you’re

using are in the same network of brokers, it’s likely that certain consumers will receive duplicate messages.

So basically, the fanout protocol is only recommended for publishing messages to multiple

nonconnected brokers.

With the fanout protocol, we come to the end of the discussion on networks of

brokers and network connectors. For reference purposes, table 4.2 provides a summary

of all the protocols covered in this section.

Table 4.2 Summary of protocols used to network brokers

Protocol            Description

Static          Used for defining networks of brokers with known addressess

Failover        Used to provide reconnection logic for clients to the network of brokers or a single broker

Multicast       Used for defining dynamic networks of brokers (broker addresses are not statically defined)

Discovery       Used by clients to connect to dynamic network of brokers

Peer            Used to easily connect multiple embedded brokers

Fanout          Used to produce messages to multiple unconnected brokers

In this section we saw that ActiveMQ isn’t just a standalone message broker; it can be

used to create complex networks and thus allow you to achieve good scalability and

微信赞赏  支付宝赞赏

【上一篇】
【下一篇】