这从这一篇开始，将讲解在activeMQ中的相关配置。由于activeMQ主要是参考apache官方网站上的说明，并在适当的地方加注说明。
一、如何配置自动重新连接
Apache官方说明：
If a JMS broker goes down, ActiveMQ can automatically reconnect to an available JMS broker using the failover: protocol. Not only does this automatically reconnect, it will also resume any temporary destinations, sessions, producers and most importantly consumers.
All of this happens silently inside the JMS client so you don't need to worry about it in your application code.
e.g. connecting to the URL
failover:tcp: < span class=code-comment >//host1:port1,tcp://host2:port2
关于Failover的更为详细的说明如下：
The Failover（故障转移） Transport（注：这里自然可以翻译为“传输”，但是从根本上来说，我认为主要是在于故障转移是在传输层完成）
The Failover transport layers reconnect logic on top of any of the other transports. (We used to call this transport the Reliable transport in ActiveMQ 3).
The Failover configuration syntax allows you to specify any number of composite uris. The Failover transport randomly chooses one of the composite URI and attempts to establish a connection to it. If it does not succeed or if it subsequently fails, a new connection is established to one of the other uris in the list.
Configuration Syntax
failover:(uri1,...,uriN)?transportOptions or failover:uri1,...,uriN
The failover transport uses random by default which lets you to load balance clients over a number of brokers.
If you would rather connect to a primary first and only connect to a secondary backup broker if the primary is unavailable, turn off randomizing using something like
failover:(tcp://primary:61616,tcp://secondary:61616)?randomize=false
这些下面的这些参数都可以通过类似http参数传值的方式failover:(tcp://host1:61616,tcp://host2:61616,...)?p1=v1&p2=v2&p3=v3 将参数p1,p2,p3传入。
Transport Options
| initialReconnectDelay | 10 | How long to wait before the first reconnect attempt (in ms) |
| maxReconnectDelay | 30000 | The maximum amount of time we ever wait between reconnect attempts (in ms) |
| useExponentialBackOff | true | Should an exponential backoff be used btween reconnect attempts （在尝试重新连接时是否使用指数回退算法） |
| backOffMultiplier | 2.0 | The exponent used in the exponential backoff attempts |
| maxReconnectAttempts | -1 >= AMQ v5.6 0 < AMQ v5.6, | From version 5.6 onwards: -1 is default and means retry forever, 0 means don't retry (only try connection once but no retry). Prior to version 5.6: 0 is default and means retry forever. All versions: If set to >0, then this is the maximum number of reconnect attempts before an error is sent back to the client. （这里要注意从v5.6版本以后出现的变化） |
| startupMaxReconnectAttempts | 0 | If not 0, then this is the maximum number of reconnect attempts before an error is sent back to the client on the first attempt by the client to start a connection, once connected the maxReconnectAttempts option takes precedence. （ 设定一个连接创建成功之前尝试连接的最大次数） |
| randomize | true | use a random algorithm to choose the the URI to use for reconnect from the list provided |
| backup | false | initialize and hold a second transport connection - to enable fast failover （ 如果backup=true，并且the URIs to use for reconnect from the list provided的数量大于一个的情况下，broker将会维护着两个连接，其中一个作为备份，在主连接出现故障时实现快速切换 ） |
| timeout | -1 | Enables timeout on send operations (in miliseconds) without interruption of reconnection process （ 默认为-1，也就是timeout为forever） |
| trackMessages | false | keep a cache of in-flight messages that will flushed to a broker on reconnect （ 设置是否缓存[故障发生时]尚未传送完成的消息，当broker一旦重新连接成功，便将这些缓存中的消息刷新到新连接的代理中，使得消息可以在broker切换前后顺利传送） |
| maxCacheSize | 131072 | size in bytes for the cache, if trackMessages is enabled （设定消息缓存时的最大缓存大小，默认为128MB） |
| updateURIsSupported | true | Determines whether the client should accept updates to its list of known URIs from the connected broker. Added in ActiveMQ 5.4 ( 设定客户端是否应该接受从连接代理更新其已知的URI列表。特性版本：ActiveMQ 5.4+) |
Example URI
failover:(tcp://localhost:61616,tcp://remotehost:61616)?initialReconnectDelay=100
If the above gives errors try it this way (this way works in ActiveMQ 4.1.1 the one above does not)
failover://(tcp://localhost:61616,tcp://remotehost:61616)?initialReconnectDelay=100
Notes
If you use failover, and a broker dies at some point, your sends will block by default.
（ 当使用failover时，如果broker失效，消息发送将默认被阻塞，下面给出两个避免阻塞的解决方法：在 中配置 ，以及设定timeout属性值）
Using can help with this regard. It is best to set the Listener directly on the so that it is in place before any request that may require an network hop. Additionally you can use timeout option which will cause your current send to fail after specified timeout. The following URL, for example
failover:(tcp://primary:61616)?timeout=3000
will cause send to fail after 3 seconds if the connection isn't established. The connection will not be killed, so you can try sending messages later at some point using the same connection (presumably some of your brokers will be available again). Timeouts on the failover transport are available since 5.3 version.
Transactions
The Failover transport tracks transactions by default. （ 故障转移的传输默认是跟踪事务的）The inflight transactions are replayed on reconnection.（ 故障发生时，尚未提交的事务将在故障转移重连之后重新执行） For simple scenarios this works ok. However there is an assumption for acknowledged (or consumer) transactions, that the previously received messages will get relayed after a reconnect. This is not always true when there are many connections and consumers, as redelivery order is not guaranteed. It is possible to have stale outstanding acknowledgements that can interfere with newly delivered messages, potentially leading to unacknowledged messages. Starting in version 5.3.1, redelivery order is tracked and a transaction will fail to commit (throw a TransactionRolledBackException) if outstanding messages are not redelivered after failover. In addition, in doubt transaction will now result in a rollback such that they can be replayed by the application.( 在5.3.1版本开始，重新传递顺序被跟踪以及事务将无法提交（抛出一个TransactionRolledBackException的异常），如果突出的消息是没有故障转移后重新传递的。此外，有疑问的事务将导致回滚，以便它们可以被应用程序重放。) In doubt transactions occur when failover happens with a commit message inflight. ( 有疑问事务出现在故障转移时有尚未提交的消息。)It is not possible to know the exact point of failure. Did the transaction commit message get delivered or was it just the commit reply that is lost? In this case, it is necessary to rollback so that the application can get an indication of the failure and deal with any potential problem.
Broker side Options for Failover（broker端的选项设置）
This is new in version 5.4:
There are some options that are available on a TransportConnector that is used by the broker that can be used to update clients automatically with information about new brokers to failover to. These are:
| updateClusterClients | false | if true, pass information to connected clients about changes in the topology of the broker cluster（ 代理群集的拓扑） |
| rebalanceClusterClients | false | if true, connected clients will be asked to rebalance（负载均衡） across a cluster of brokers when a new broker joins the network of brokers |
| updateClusterClientsOnRemove | false | if true, will update clients when a cluster is removed from the network. Having this as separate option enables clients to be updated when new brokers join, but not when brokers leave. 动态更新连接到server的broker cluster的结构 |
| updateClusterFilter | null | comma separated list of regular expression filters used to match broker names of brokers to designate as being part of the failover cluster for the clients （ 这是一个用逗号分隔的正则过滤集合，它用来匹配broker的名字，符合条件的broker将被用于故障转移） |
| updateURIsURL | null | A URL (or path to a local file) to a text file containing a comma separated list of URIs to use for reconnect in the case of failure |
An example as defined within the broker's XML configuration file:
< broker > ... < transportConnectors > < transportConnector name ="openwire" uri ="tcp://0.0.0.0:61616" updateClusterClients ="true" updateClusterFilter ="*A*,*B*" /> </ <transportConnectors> ... </ broker >
If updateClusterClients is enabled, then your clients will only need to know about the first broker to connect to in a cluster of brokers - e.g.:
failover://tcp://primary:61616
If new brokers join, the client will automatically be updated with the additional URI of that broker to connect to in the event of a network or broker failure.
More Information
Also check out the following blog entry about using the cluster client updates and rebalancing features titled .
Priority Backup（指定备份代理集合中的优先级）
If your setup have brokers in both local and remote networks, you probably want your clients connected to the local ones if those are available. As of version 5.6, ActiveMQ supports priority backup feature, so you can have your clients automatically reconnect to so called priority (or local) urls. Consider the following url
failover:(tcp://local:61616,tcp://remote:61616)?randomize=false&priorityBackup=true
If this url is used for the client, the client will try to connect and stay connected to the localbroker. If local broker fails, it will of course fail over to the remote one. But as priorityBackupparameter is used, it will constantly try to reconnect to the local broker. Once it can do so, the client will get back to it without any need for manual intervention.
By default, only the first url in the list is considered prioritized (local). In most cases this will suffice, but in some cases you can have multiple "local" urls. You can configure which urls are considered prioritized, by using priorityURIs parameter, like
failover:(tcp://local1:61616,tcp://local2:61616,tcp://remote:61616)?randomize=false&priorityBackup=true&priorityURIs=tcp://local1:61616,tcp://local2:61616
In this case the client will prioritize either local1 or local2 brokers and (re)connect to them if they are available.