ActiveMQ in Action-4.5 Network connectors- 高飞网

4.5 Network connectors

——网络连接器

2016-05-17 17:44:15.0

4.5网络连接器

    服务端网络连接器创建了一个由多个ActiveMQ实例构成的集群,他们之间相连互通以适应更高要求的消息场景。服务端网络的许多拓扑结构,其目与配置细节,都会在第10章详细讲解。前面的章节讨论了提供client-to-borker通讯的协议连接器(protocol connectors)。而本节将讨论供broker-to-broker通讯的网络连接器(network connectors)。

    网络连接器指的是配置在服务端之间的一些通道,以使服务端之间能够可以通讯。网络连接器默认情况下是单向的。一个给定的服务端在一个方向上转发消息,在另一个方向上接收消息。这种设置经常被称为转发桥(forwarding bridge)。有些情况,你可能想在服务端之间创建一个双向的通讯通道,那时的通讯不仅在连接的一端面向服务端之外,而且也会从相同的通道中从其他服务端接收消息。

    ActiveMQ支持这种双向连接器,经常被称为duplex connector。图4.5示例了一种服务端网络,包括单向和双向连接器。


    网络连接器在配置文件中的配置方式与协议连接器非常之相似,看下面的配置:

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

    

    正如你看到的,服务端网络配置时使用<networkConnectors>节点。这个节点包含了一个或多个使用<networkConnector>元素的连接器配置。就像协议连接器,必需的属性是name和uri参数。其他所有的都是可选项,用来配置连接器的附加特性,稍后就会看到。

    在接下来的章节中,会讲到被用来配置并连接到服务端网络的许多ActiveMQ协议和技术,但是在我们深入了解它们之前,关于ActiveMQ一个重要概念,我们得先解释一下。这个概念称为发现(discovery),通常,发现是一个探测远程服务端服务的过程。客户端想发现所有的可用服务端;另一方面,服务端想通常想找到其他可用的服务端,所以它们之间可以建立一个服务端网络。

    当你想配置服务端网络时,第一个明显的问题就是,你知道网络中每个服务端确切的网络地址吗?如果知道,你就可以静态地配置你的网络,并且也可以把客户端连接到预定的服务端URI。这种情况经常发生在生产环境,你想把控所有的资源。在4.5.1节中,向你展示了如何设置和使用静态网络。首先会解释用以把多个服务端连接在一起的静态协议(static protocol)。然后,我们会讲解一种失败转移协议(failover protocol),这种协议可以将客户端连接到网络中的一个服务端,另外它还有重连逻辑。

    在客户端和服务端都相互不知道各自的网络地址时,就必须用另一种发现机制(discovery mechanism),从而动态地定位可用的服务端。这种情况经常发生在开发环境中,因为它更容易配置和维护。发现代理和它使用的协议在4.5.2节介绍。你会学到broker如何使用IP组播协议通知他们的服务,并且使用组播连接器定位其他的可用brokers。我们也将会看到端如何使用组播连接器发现使用发现连接器的服务端。

    我们将会深入这个尊贵的连接器,它把创建嵌入式服务端网络变得非常简单。最后,我们会看看fanout connector是如何让客户端向多个服务端发送消息的。下面让我们从静态网络开始(static networks)。


4.5.1 静态网络(Static networks)

    配置并连接到服务端网络的第一种方式是通过使用静态配置的URI——配置一个可用于连接的服务端uri列表。仅有的先决条件是,你要知道你想使用的所有服务端的网络地址。一般你得到这些URI了,你只需要知道如何在配置文件中使用它们即可。所以让我们看看这个创建静态网服务端网络的连接器。


静态连接器(STATIC CONNECTOR)

    静态连接器是用于在一个网络中创建多个服务端的静态配置的。这种协议使用一种复合URI,复合URI中又包含了其他的URI。这个复合的URI包含了多个服务端地址,或者在网络接连的另一端的URI。

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

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

你可以在ActiveMQ官网(http://mng.bz/r74v)查看这种传输的完整规格说明。

现在看下在配置文件中的配置:

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

    假设该配置文件是在本地的服务端,而两个远程服务端remotehost1和remotehost2已经启动起来了,那么当你启动本地服务端时,你会注意到下面的信息:

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

    上面的输出表明,本地服务端已成功地与另外两个远程的已经启动的服务端配置了单向桥,换句话说,发送到本地服务端的消息也会转发到另外两个运行着的服务端(remotehost1和remotehost2)上面,但前提是消息消费者有这样的需求。

    理解该文案的最好方式是利用股票投资示例,在服务端网络中使用一下静态网络配置。图4.6提供了这个示例服务端拓扑的预览图。


    在图中,两个服务端是相连的。服务端通过静态协议使用带URI的网络连接器去。消费者依附在服务端B,而服务端B为消息跨越网络创建了需求。当生产着发送到服务端A的相同目的地时,消息会被转发到有需求的服务端上。这种情况下,服务端A会转发消息到服务端B。下面的示例将演示这种基本的情况:

要想让示例跑起来,首先要启动两个网络中的服务端:

对于服务端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>

    这个示例配置监听于61617端口,用下面的命令启动它:

${ACTIVEMQ_HOME}/bin/activemq console \
xbean:src/main/resources/org/apache/activemq/book/ch4/brokerA.xml

现在来配置服务端A:

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

    而这个连接器监听的是61616端口,这里定位了一个连接到服务端B的网络连接器。在另一个控制台容器,你可以启动这个服务端:

${ACTIVEMQ_HOME}/bin/activemq console \
xbean:src/main/resources/org/apache/activemq/book/ch4/brokerA.xml

    现在已经服务端已经启动运行起来,让我们运行下股票投资示例。首先启动消息发布者并连到服务端A:

$ 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


    这个实际上与之前TCP连接器示例几乎一样。现在启动消费者并将之连接到服务端B:

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

    使用这个设置,消息会发布到服务端A。然后这些消息然后会被转发到服务端B。在那被消费者接收。该示例的整体功能没有变化,并且消息发布者和消费者的行为看起来和之前的单服务端也一样。仅有的不同是,发布者和消费者现在连接到的是不同的服务端,这些服务端使用静态协议连接在一个网络中。

    从这个简单的例子中我们可以看出,当你想让你的分布式环境的客户端充分利用与本地服务端的通讯优势而非远程服务端时,这个特别的配置就可以帮到你。


静态协议使用示例

    配置服务端网络,依据环境的不同可能变得非常困难。能够使用静态协议的一个明确的前提是网络必须存在。考虑下这样的情况,在远程办公网络中的客户端要连接到家庭网络中的服务端。根据远程办公网络中的客户端的数量,有可能就需要很多多的广域网连接到家庭网络。这可能会导致网络的低可用性。为了最小化连接数量,你可能想在每个远程办公网络都配置一个服务端并允许其连接到家庭网络中。这不仅仅最小化了远程办公网络和家庭办公网络的之间的网络连接数,而且它允许远程办公网中的客户端应用处理更高效。取消了在广域网上的长期连接,这意味着更少的延迟,因此对客户端应用来说就是更少的等待。


失败转移协议(FAILOVER PROTOCOL)

    至今为止所有的示例中,客户端的配置都是连接一个服务端。但是当你没有连接到你期望连接的服务端时,或者你的连接在后期失败了怎么办?你的客户端有两个选择:要么优雅的宕机,要么尝试连接到相同的或其他的服务端并继续当前的工作。正如你看到的,至今为止,股票投资项目中使用的都是之前描述的协议,它不能对网络问题和不可用服务端做出正确的反应。这就是failover协议可以引入的地方并实现动态连接。与网络连接器相似,有两种方式可以提供一个合适的可连的服务端列表。第一种,提供一个静态的可用服务端列表,这是failover协议所采用的方式。第二种,动态地发现可用服务端。这将在下一节讲到。这节将测试failover协议连接器。

失败转移协议的URI语法与首页所讲的静态网络连接器相似,下面是两种可用的格式:

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

或:

failover:uri1,...,uriN

    这种协议的完整说明请参考ActiveMQ官网(http://mng.bz/u58s)。

    默认情况下,该协议使用随机算法在潜在的连接中选择一个。如果连接失败了(启动时或者之后),传输连接器将选择另外一个URI并尝试连接上它。默认配置同时也实现了延迟重连逻辑,意味着传输器将在10ms后开始第一次重连尝试,每次将该延迟时间翻倍再去尝试重连,直到30000ms。重连逻辑也会尝试无限地重连。当然,所有的重连参数可以根据你的需要使用合适的传输选项重新配置。

    回忆一下前面定义的服务端静态网络概念。在那个示例中,发送到本地服务端的所有消息都会被转发到位于remotehost1和remotehost2上的服务端。因为所有的消息都会发送到这两个服务端,所以哪个服务端都可以消费消息。这里也是一样的。仅有的不同是,失败转移协议一旦失败会自动尝试会重连服务端。为了体验一下这种协议的使用,运行股票投资项目,使用失败转移协议配置他连接到服务端。

$ mvn exec:java -Dexec.mainClass=org.apache.activemq.book.ch4.Consumer \
-Dexec.args="failover:(tcp://remotehost1:61616,tcp://
remotehost2:61616) CSCO ORCL"

    这种方案的好处就是,对于应用来说,一旦发生服务端连接失败时,他不需要再为了支持自动重连而做任何改变。

    现在,让我们看看失败转移连接器如何工作。试想一下,失败转移传输连接器中的随机算法已经把消费者连接到host1的服务端上,消费者会预期的打印下面的启动信息:

org.apache.activemq.transport.failover.FailoverTransport$1 iterate INFO: \
Successfully reconnected to tcp://host1:61616

    正如我们说过的,发布者向本地服务端发送的所有消息将转发到host1,并被消费者接受。现在尝试通过shutdown掉host1的服务端去模拟连接失败。消费者将打印下面的信息:

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

    注意,异常信息解释了错误的原因,紧跟其后的是关于重连到另一个服务端的日志消息。这意味着消息者已经成功连接到另一个服务端,并且在没有任何外在干预的情况下继续正常的工作。


使用失败转移协议示例(EXAMPLE USE OF THE FAILOVER PROTOCOL)

    鉴于它的重连能力,因此你把失败重连协议用于所有的客户端都是非常适合的,即使只连到一个服务端。例如,下面的uri将会在服务端在shutdown或其他原因连接失败时尝试重新连接到新客户端:

failover:(tcp://localhost:61616)

    这个方案的好处是在服务端失败的情况下,你不需要手工地重启客户端。一旦服务端重新可用了,你的客户端会自动重连。这意味着通过简单地利用ActiveMQ的特性使你的应用更为健壮。

失败重连协议在实现高级的功能,如高可用,负载均衡等都扮演着重要的角色,后面的12章会讲到。 


4.5.2 动态网络(Dynamic networks)

    到现在为止我们已经设置了服务端网络并通过明确地指定具体的服务端URI(传输器和网络连接器)连到它们。正如你在本节看到的,ActiveMQ实现了几个机制,用以让服务端和客户端之间发现彼此并建立有效的连接。


组播连接器(MULTICAST CONNECTOR)

    IP组播(multicast)是一种网络技术,用于简单从一个源向一组感兴趣的接收者通过IP网络传输数据(一对多(one-to-many)通讯)。IP组播最基础的网络概念之一,称被为组地址(group address)。组地址是一个IP地址段从224.0.0.0 到 239.255.255.255,供源和接收者使用。源使用该地址作为一个它们数据的目的地,而接收者用它传递它们在那个组上的感兴趣的数据。当IP组播配置了以后,ActiveMQ服务端使用组播协议通知他们的服务,并为了创建服务端网络而定位其他服务端的服务。另外,客户端使用组播去定位服务端并与之建立连接。本节将介绍服务端如何使用组播,稍后再探讨客户端使用组播。

组播协议的URI语法如下:

multicast://ipadaddress:port?key=value

这与前面的URI没有什么例外。

下面是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>

    在这个示例中,组名称default用于代替一个指定的IP地址,该配置片段中有两个重点。首先,传输连接器的discoveryUri属性用于通知默认组的传输器的URI。那些为了发现可用服务端的所有客户端都会使用这个连接器。这个会在后面介绍。

    其次,网络连接器的uri属性是用于查找可用的服务端并与他们建立网络。在这种情况下,服务端可以看做是一个客户端,并使用组播去达到查找的目的。可以在ActiveMQ官网(http://mng.bz/14yJ)查看这种协议的完整说明。

    既然你知道了在服务端如何配置这种发现协议,我确信你很想知道在中协议的使用场景。


组播协议使用示例(EXAMPLE USE OF THE MULTICAST PROTOCOL)

    组播协议与TCP有点不同。区别在于自动发现其他的服务端,而不是配置一个静态的服务端uri列表。通常在那些需要频繁地增加或移除服务端的场景中会使用组播协议。这种情况下,不会每次环境的改变都手工地维护服务端配置,而是会简单地利用发现协议去实现。


防止自动服务端发现(Preventing automatic broker discovery)

当在一个团队环境中开发时,两个或多个ActiveMQ实例将自动连接到另一个并开始消费另个的消息是有可能的。这里有一些建议可以防止这种情况的发生:

1 移除openwire传输连接器的discoveryUri部分。这个名为openwire的传输连接器默认的配置会通过组播通知服务端TCP传输器。这允许其他的服务端自动的发现它并在有需要时连接上。

下面就是conf/activemq.xml配置文件中的OpenWire连接器定义:

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

为了阻止服务端通过组播通知TCP传输器,修改上面的默认定义,移除掉discoveryUri,之后看着如下面的样子:

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


2 注释或删除名为default-nc的网络连接器——它利用组播传输去自动和动态的发现其他服务端。为了阻止这种行为,注释或移除这个网络连接器,使它不能自动发现其他的服务端。下面是conf/activemq.xml配置文件定义的default-nc网络连接器:

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

禁用这种网络连接器,注释掉如下:

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


3 给服务端一个唯一的名称——conf/activemq.xml配置文件中的ActiveMQ默认配置提供了一个服务端名为localhost,如下:

<broker xmlns="http://activemq.apache.org/schema/core"

brokerName="localhost"

dataDirectory="${activemq.base}/data">

为了唯一地标识你服务端实例,把服务端名称由localhost变为一个唯一的字符如下:

<broker xmlns="http://activemq.apache.org/schema/core"

brokerName="broker1234"

dataDirectory="${activemq.base}/data">

当通过日志搜索或查看上哪个服务端发生某个行为时是非常方便的。


    使用组播协议的一个缺点是,发现是自动的。如果有些服务端你不想被自动的添加到给定的组中,那么在你初始化服务端网路配置的时候必须小心。仔细区别开这些服务端是很重要的。因为你不想让你的消息在不属于他的网络中消费。另外一个缺点是这种协议在网络中过度地交互。因为这个,很多网络管理员不允许使用它。在花费时间去配置这种组播协议网络之前,请询问下你的网络管理员。就像服务端可以使用IP组播去发现服务一样,客户端也有一个简单的发现协议。


发现协议(DISCOVERY PROTOCOL)

    发现协议是客户端的ActiveMQ组播功能。这个协议基本上与失败转移协议(failover protocol)的表现行为一致。仅有的区别是他使用组播去发现可用的服务端,并随机选择一个区连接。

发现协议的URI语法是:

discovery:(discoveryAgentURI)?key=value

    这种协议的完整说明请参考ActiveMQ官网(http://mng.bz/96wI)。

    使用足部服务端配置之前已说过,你可以使用下面的命令运行服务端:

${ACTIVEMQ_HOME}/bin/activemq console \
xbean:src/main/resources/org/apache/activemq/book/ch4/activemq-multicast.xml

一旦服务端启动,就可以用下面的命令运行服务端发布者:

$ mvn -e exec:java \
-Dexec.mainClass=org.apache.activemq.book.ch4.Publisher \
-Dexec.args="discovery:(multicast://default) CSCO ORCL"


在应用启动时,你可能回注意到下面的日志信息:

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


这些日志告诉你发布客户端已经成功地使用组播协议去发现并连接到本地服务端了。


对等协议(PEER PROTOCOL)

    像我们之前看到的,服务端网络和嵌入服务端都是很有用的思想,他们允许你根据你基本的功能定制你的服务端。当然,理论上也是可以创建嵌入式服务端网络的,但这将手动地配置起来很麻烦。这就是为什么ActiveMQ提供了peer传输连接器的原因。

因为他让你使用嵌入式跟为容易,对等连接器是一个实用协议,他是VM连接器的超级,创建了一个点对点(peer-to-peer)的嵌入服务端的网络。

协议的语法如下:

peer://peergroup/brokerName?key=value

    你可以在ActiveMQ官网(http://mng.bz/bIaH)看到完整的说明。

    当你带着配置了对等协议URI启动时,应用将会自动启动嵌入式服务端(就像VM传输协议一样),但是他也会与配置的相同组的其他服务端建立网络。

    让我们用股票投资项目的示例体验一下对等协议。这种情况下,发布者和消费者都会用他们自己的服务端,并且服务端也会自动的组成网络。图4.7提供了这种方案的更好的预览。


    像下面命令中用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
...


同样像下面命令中用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
...


    上面的两个命令启动了两个嵌入式服务端(都对应各自的应用),并在两个服务端之间创建了一个对等(peer-to-peer)服务端网络,名为group1.所有发送到第一个服务端的消息,在其他的服务端也是可用的。同事,其他的服务端也可以加入到group1中。注意:整个系统就像使用了一个相同的中心服务端一样。

对等协议使用示例(EXAMPLE USE OF THE PEER PROTOCOL)

    考虑现场销售代表的笔记本上的应用,经常会与公司的网络断开,但是任然需要让应用在断线状态正常地运行。这是个常见的场景,客户端应用不管网络是否可用,都需要正常的工作。这种情况下,对等协议可以被用于嵌入式的服务端,以使得笔记本中的应用可以保持正常地运行。事实上,当在断线模式下,应用知识简单地将消息发送到本地服务端,然后消息在之后网络连接再次可用的使用排队发送。再网络断开时,销售代表任然可以记录客户端调用,访问等等。而当笔记本再次连接到网络时,所有的队列中的消息都会被发送到并被消费客户端消费。


扇出连接器(FANOUT CONNECTOR)

    扇出协议是另一个使用的连接器,被客户端用以同时连接到多个服务端,并且复制操作到这些服务端(replicate operations to those brokers). URI语法如下所示:

fanout:(fanoutURI)?key=value

你可以在ActiveMQ官网(http://mng.bz/J7i0)看到完整的使用说明。

fanoutURI可以利用静态URI或组播URI。考虑下下面的示例:

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

在图4.8中,客户端试图连接到使用静态协议定义的三个服务端。



相同效果也可以简单的用下面的URI实现:

fanout:(multicast://default)


    这假定服务端配置使用服务端去通知他们的传输连接器。默认情况下,扇出协议将一直等待,知道它连接到至少两个服务端,并且不会复制命令到queue中(只有topic),当然这些特性,都是可用适当的传输参数配置的。

    最后,在使用扇出协议时,有两点你必须要注意。首先,不建议用于消费消息。他仅有的目的是为了生产消息到多个服务端。然后,如果你使用的服务端在相同的服务端网络中,有可能有某些消费者受到相同的消息。所以,扇出协议仅建议用于发布消息到多个未连接的服务端。

    扇出协议是我们服务端网络和网络连接器最后讨论的。为了参考之目的,表4.2提供了一个本章所有协议的小结:


协议
描述
静态协议(Static)
通常通过已知地址定义服务端网络
失败转移协议(Failover)
通常为客户端连接到服务端网络或单个服务端提供重连逻辑
组播协议(Multicast)
用于定义动态服务端动态网络 (服务端地址不是静态定义的)
发现协议(Discovery)
客户端用一连接到动态的服务端网络
对等协议(Peer)
用于简单地连接到多个嵌入式服务端。
扇出协议(Fanout)
用于发布消息到多个服务端

    本节中我们看到,ActiveMQ不仅仅是一个单独的消费服务;它可以用于创建一个复杂的网络,因此可以让你的消息框架获得更好的可扩展性和可用性。