4.5 网络连接器

4.5 Network connectors

4.5 网络连接器

 

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.

 

代理的网络会创建一个代理集群,该集群包含多个相互连接着的ActiveMQ实例,以满足更高级的消息系统场景的应用.

第10章中会讨论各种代理网络的拓扑结构,使用该拓扑结构的目的以及拓扑结构的配置细节.前面章节中讨论的

传输连接器用来满足客户端-代理之间的通信,而接下来的章节将要讨论的网络连接器用来满足代理-代理

之间的通信.

 

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.

 

网络连接器是用来配置代理间互相通信的通道.默认情况下,网络连接器是单向通道.

代理的单向通信是指:代理只将其收到的消息发送到收消息连接另一头的代理.(译注:

这就是说 代理A从代理B收到消息,然后只将消息转发到除B之外的代理,就是说代理A不会既从代理B

接收消息,同时也发送消息到B)这个过程通常被看成是转发桥.有时,你可能想要创建双向的通信通道,即

代理使用这种通道后,不仅能朝连接另一头的代理发送消息同时也能从连接另一头的代理接收消息.

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>

 

在ActiveMQ的XML配置文件中,配置网络连接器和配置传输连接器类似.下面是一个配置实例:

<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.

 

如你所看到的,实用<networkConnectors>元素配置代理的网络连接器,这个元素使用一个或多个

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

元素时,name和uri属性是必须要配置的.所有其他属性都是可选的,稍后你将看到,使用这些属性可以为网络连接器

配置额外的功能.

 

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.

 

本章的其余部分会讨论ActiveMQ的各种网络连接协议和技术,以便配置和连接到一个代理网络.

在详细讨论之前,需要解释ActiveMQ的一个重要的概念--侦测.通常,侦测是一种搜寻远程代理

服务的过程.通常,客户端希望能够侦测到所有可用的代理.另一方面,代理也希望能够侦测到其他可用的代理,

以便可以和他们建立一个代理网络.

 

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.

 

在配置一个代理网络之前,首先需要了解的问题是:你知道网络中每个代理的地址吗?

如果答案是肯定的,你就可以配置静态网络,然后让客户端连接到事先配置好的URI.

在这种常见的生产环境中,你希望能够控制所有的网络资源. 4.5.1小节的内容解释了

如何设置和使用静态网络.该小节从解释将多个代理互联在一起的静态协议说起,然后,解释了

失效转移(failover)协议,该协议允许客户端使用重连机制连接到代理网络中的一个代理.

 

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.

 

为了防止客户端和代理之间不能识别对方的网络地址,他们必须使用一种侦测机制,以便能动态的定位

可用的的代理.这种机制通常用于开发环境中,因为便于设置和维护. 4.5.2小节解释饿了侦测工具和使用的

协议.你将学习代理如何使用IP地址的多点传送技术来提供服务和定位其他可用的通用使用了多址通信连接器的代理.

通样,我们将看到客户端如何使用多址连接器来侦测使用侦测连接器的代理.

 

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.

 

我们还会讨论点对点的连接器,这使得创建一个由嵌入式代理组成的网络变成了一个非常简单的任务.

最后,我们将看到fanout连接器运行客户端端发送消息到多个代理.

下面让我们从静态网络开始.

 

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.

 

配置连接到一个代理网络的第一中方式是配置静态的URI--即,为连接配置一组可用代理的URI.

唯一的先决条件是你需要事先了解将要使用的代理的URI.一旦你了解了这些URI,你即可知道如何

将它们用于配置.所以,让我们来看看可用于创建代理静态网络的连接器.

 

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.

 

静态网络连接器用于为一个网络中多个代理创建静态配置.这种配置协议使用了一种复合的URI--即包含其他URI的URI.

一个复合RUI包含该代理所在网络中多个地址或URI.

 

Here’s the URI syntax for the static protocol:

下面是静态协议使用的URI语法:

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

 

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

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

有关这种传输方式的完整文档请参阅ActiveMQ网站(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:

 

假设上面的代码是配置一个本地代理的,同时远程主机remotehost1和remotehost2上的代理在正常运行,当

启动本地代理时,你将看到下面的提示信息:

(译注:远程的主机上必须启动了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.

 

从上面的输出信息可以看出,本地主机上的代理成功的配置了一个转发消息到两个远程主机代理转发桥.

换句话说,就是发送到本地代理上的消息将被转发到运行在远程主机remotehost1和remotehost2上的代理.

但是,只有消息消费者(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.

 

理解这种机制的最佳方式是,在静态网络中,使用代理网络运行stock portfolio实例.图4.6展示了本例中使用的

代理的拓扑结构.

 

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.

 

在图4.6中,两个代理使用网络连接在以前.代理利用了网络连接,该网络连接借助静态协议URI来配置.

一个消息消费者将BrokerB设置为消息的目的地(即从这个目的地接收消息然后处理),因此这个消息

消费者就要求消息穿过网络界面.代理A上的消息发布者发送消息给相同的目的地,这就要求代理转发消息.

这种情况下,BrokerA将消息消息转发到BrokerB.

下面的例子将梳理以便这个基本用例.

 

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

Let’s start with BrokerB:

为了让这个例子正常正式,首先,我们需要启动这两个互联在以前的代理.

使用下面的配置启动代理B:

 

<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修改即可,

主要改了beans元素里面的主题schema部分,复制即可.另外改了dataDirectory="${activemq.data}"这个)

 

Now it's time to configure BrokerA:

下面配置BrokerA:

<broker xmlns="http://activemq.apache.org/schema/core" brokerName="BrokerA" dataDirectory="${activemq.base}/data">

  <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:

 

上面代码除了配置监听61616端口的传输连接器外,还定义了一个网络连接器用来连接到代理B(BrokerB).

在另一个命令行窗口,你可以使用下面的命令启动这个代理(代理B,BrokerB)

 

${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.

现在两个代理都运行起来了,可以运行stock portfolio这个例子了.

 

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

首先,使用下面的命令运行publisher并让它连接到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.

 

通过上面的设置,消息被发布到BrokerA,接下来被转发到BrokerB,然后consumer从BrokerB接收消息.

这个例子的整个功能没有改变,publisher和consumer的行为和之前使用单个broker的例子中的行为

是一样的.这里唯一的编号是publisher和consumer连接到了两个不同的代理上,这两个代理通过静态

协议组成了代理网络.

 

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

help you in situations when you need your distributed clients to benefit from the performance

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.

 

到目前为止的所有例子中,客户端都被配置成只能连接到一个代理.但是,

假如遇到下面的情况你该如何处理:你不能连接的目标代理,或者你的连接失败了?

此时,你的客户端有两种选择:优雅的挂了或者尝试连接原来的代理或连接其他的代理并恢复正常功能.

你可能已经猜到,目前为止运行stock portfolio这个例子所使用的协议不能处理网络问题也不能

处理代理失效问题.此时实现了自动重连的效转移协议应运而生.与网络连接器类似,有两种方式可以为客户端提供

一组可用代理.第一种情况,你可以提供一组静态的代理.这种方式用于时效转移传输连接器.

另外一种情况是使用动态侦测可用代理.本章稍后将讨论相关内容.本小节将探讨失效转移连接器.

 

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:

失效转移连接器的URI语法和之前静态网络连接器的RUI语法类似.实际上,有两种方式可配置失效转移

连接器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).

失效转移协议的完整文档请参阅ActiveMQ网站(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.

 

默认情况下,该协议使用一种随机算法来选择一个可用的连接器.如果连接失败(在启动时或者稍后某个时候),

传输连接器会选择另外一个URI然后尝试建立连接.默认的配置同样实现了延迟重连逻辑,即,

传每个失效转移输连接器在启动之前会有10ms的延迟,这段延迟时间用于尝试首次的重连.后续的重连(译注:如果需要的话)

将延长这个延迟时间,但是延迟时间总数不会超过30000ms.此外，连接逻辑将无限期地尝试重新连接。

当然,使用适当的传输连接器选项,所有连接参数都可以根据需求重新配置.

 

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:

回忆前面章节中定义的理论上的静态代理网络,在那个例子中所有发送给本地代理的消息都会被转发到

运行在remotehost1和remotehost2上的远程代理.因为所有的消息都能被转发到这两个远程代理,所以这些

消息可以被任何一个代理接收.这里使用失效转移连接器也是一样,唯一的区别是失效转移连接器只在目标代理失效时

自动尝试重新连接到其他代理.为了尝试使用这种连接器,使用下面的命令运行stock portfolio这个例子,并且配置该例子

中的consumer连接到失效转移连接器:

 

$ 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:

正如我们前面所说过的,所有publisher发送到本地代理的消息都将被转发到host1上的代理然后被consumer接收.

接下来通过关闭host1上的代理来模拟一次代理失败.此时consumer将打印下面的日志信息:

 

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

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

at java.io.DataInputStream.readInt(DataInputStream.java:375)

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

at org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:192)

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

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

at java.lang.Thread.run(Thread.java:619)

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.

 

在上面的例子中,使用群组名称"default"来替代具体的IP地址.上面的配置代码片段中有两个地方比较重要.

首先,transport connector的discoveryUri属性用于暴露这个传输连接器的URI到名称为default的群组中.

所有的希望查找可用代理的客户端都可以使用这个代理,这在稍后的章节中会有说明.

 

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).

 

其次,network connector的uri属性用于查找可用的代理并与之建立代理网络.这样配置后,代理就像客户端

一样,使用多点传送协议来查找其他代理.多点传送协议的完整文档请参阅ActiveMQ站点(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. 

 

多点传送协议与TCP协议稍微有些不同.它们的不同点在于多点传送协议使用自动侦测其他代理而TCP

协议使用一组静态代理.

 

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:

 

在团队开发中,可能(而且极有可能)同时启动两个或者多个ActiveMQ代理,并且这些代理会自动连接到彼此,然后

影响彼此的消息处理.这里是阻止这种情况发生的几个建议:

 

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的传输连接器

因使用多点传送因而暴露它的TCP传输连接器.这就允许其他代理自动的侦测到以便在需要的时候连接它.

 

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

configuration file:

下面是conf/activemq.xml文件中OpenWire传输连接器的定义:

 

<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:

为了阻止代理通过多点传送而暴露TCP传输连接器的URI,需要修改定义,移除discoveryUri属性,

使得配置信息看起来如下所示:

<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利用多点传送可以动态的自动

侦测其他代理.为阻止这中行为,注释掉/移除default-nc网络连接器以便其不会自动侦测其他代理.

 

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

configuration file:

下面是conf/activemq.xml文件中关于名称为default-nc的定义代码:

<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用下面的代码配置了一个

名称为localhost的代理:

<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.

 

当需要添加代理或者移除代理时经常使用多点传输协议,以便不用频繁的修改代理的IP.这样,不必每次都

手工修改以便重新配置代理,而是常常利用侦测协议.

 

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

administrators won’t allow its use. Please check with your network administrator

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).

自动侦测协议的完整文档请参阅ActiveMQ站点(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.

 

上面的信息显示,客户端publisher已经成功了利用多点传输协议侦测并连接到一个本地代理.

 

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.

 

正如前文你所看到的,代理网络和嵌入式代理是有用的概念,他们允许你定制代理以便符合基本的需求.

当然,理论上是可以创建嵌入式代理网络的,但是这样的手工配置看起起来显的十分笨重.此时ActiveMQ的

点对点连接器应运而生,使得创建嵌入式代理网络变得更加容易.点对点连接器是一种传输连接器网络,是构成

点对点的嵌入式代理网络中所有虚拟连接器的集合.

 

The URI syntax of this protocol is as follows:

点对点协议的URI语法如下:

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.

 

使用一个点对点协议的RUI启动应用程序会自动启动一个嵌入式代理(就像使用VM协议一样),同时还会

配置代理以建立到本地网络中群组名称相同的其他代理的连接.

 

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.

 

让我们详细阐述如何在stock portfolio例子中使用这种点对点协议.在这个例子中,publisher和consumer

都将使用他们自己的嵌入式代理,这两个代理会也懂的建立网络.图4.7显示了该方案的概览.

 

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

group1 like this:

使用下面的命使得的tock portfolio例子中publisher创建它自己的嵌入是代理,并将其群组名称设置为

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.

 

上面的两个命令启动了两个嵌入式代理(每个应用启动一个代理),并让这两个代理组成了一个点对点的代理网络,该代理网络

名称为group1.所有发送到两个代理之一的消息对于其中的另外一个代理或者其他可能加入到group1群组中的代理来说都是可用的.

注意,在整个系统中,所有的操作看起来就好像这两个应用都在使用相同的代理.

 

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).

有关Fanout协议的完整文档请参阅ActiveMQ站点(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

图4.8中,客户端将尝试连接掉3个使用静态协议配置的静态代理.

 

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

fanout:(multicast://default)

也可以使用下面的URI配置以达到同样的效果:

 

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.

 

这里假设使用多点传送协议配置的代理暴露了它们的传输连接器.默认情况下,fanout协议将等待一段时间,直到它至少连接

到连个代理并且不会在消息队列上重复执行命令(只针对消息主题重复执行命令).当然,上面两种特性都是可以通过使用合适的参数

来配置.最后,如果你打算使用fanout(扇出)协议,你需要关注有一些问题:首先,在接收消息是不推荐使用扇出(fanout)协议.使用

改协议的目的是发送消息到多个代理.其次,如果你使用的代理属于同一个代理网络,那么指定的消息消费者可能会接收

到重复的消息.因此,通常情况下,fanout协议仅用于发布消息到多个相互之间没有连接在一起的代理.

 

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.

 

讨论完扇出(fanout)协议后,对于代理网络和网络连接器的讨论也接近尾声了.为方便参考期间,表4.2中

列出了本节中所有协议的总结.

 

Table 4.2 Summary of protocols used to network brokers

表4.2 代理网络中用到的协议总结

 

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

availability of your messaging infrastructure.

 

本节中我们看到ActiveMQ不仅仅是单一的消息代理,也可以创建复杂的代理网络以便实现高可伸缩性和

高可用性的消息系统.