我司使用TIBCO做为JMS中间件，最近需要做应用的JMS相关容错测试，因此对TIBCO的容错性做了粗浅的研究。

TIBCO提供了主备模式的容错设计，通过配置一对服务器（一主一备）进行容错。正常情况下，主服务器接受客户端的连接和传递消息，一旦主服务器出现故障，备份服务器变为主服务器继续工作，原来的主服务器恢复后，变为备份服务器。

架构上可分为：共享状态模式、非共享状态模式。非共享状态模式在故障切换的时候会出现消息丢失、重复等问题。我司目前使用的是共享状态模式。

共享状态

为了提供最大程度的故障切换保护，主服务和备份服务必须共享相同的状体，这些状态包括三个方面：
1、 持久化的消息数据
2、 主服务的客户端连接
3、 消息传递的元数据
当发生切换时，备份服务器重读所有共享信息。

共享状态故障切换过程

发现

备份服务器发现主服务器故障有两种方式：
1、心跳故障：主服务器通过向备份服务器发送心跳消息，表明它仍然在运行。当网络发生故障，造成服务器间停止交互时，备份服务器可以检测到稳定的心跳被打断。
2、连接故障：备份服务器可以检测到与主服务器的TCP连接失败。当程序意外终止时，备份服务器发现连接断开。
当的主服务器心跳停止，备份服务器等待其激活间隔。默认心跳间隔是3秒，激活间隔是10秒。

响应

当备份服务器（用B替代）检测主服务器（用A替代）的故障时，则试图让自己成为主服务器。首先，B获得当前共享状态的锁，能够获取，它就变成了新的主服务器。若B无法获立即取共享状态的锁，它在试图获取锁（得到锁并成为主服务器）和尝试重新连接到A之间交替操作，直到其中一个成功。

角色颠倒

当B成为新的主服务器时，可以重新启动A 作为备份服务器，让服务器交换角色。

客户端转移

当B成为新的主服务器后，客户端自动转移到B。B从共享存储中读取客户端的当前状态，向客户端发送持久消息。
当容错切换发生时，客户端会收到通知。Java 客户端程序定义一个ExceptionListener 来接收容错切换通知，客户端设置system property tibco.tibjms.ft.switch.exception为任意值。 但API文档说明相关操作有死锁风险（NOTE: when the exception listener is called, the exception listener is not allowed to call any EMS method. To do so in this case risks a deadlock in the client.）。

配置客户端容错连接

客户端的连接URL可以指定用逗号分隔的多个服务器地址，例如：tcp://server0:7222, tcp://server1:7344。客户端会按顺序试图连接，如果第一个连接失败会连接第二个。
在容错切换过程中，客户端会尝试重连到备份服务器。默认情况下，客户端将尝试重联4次，每一次尝试有500毫秒延迟。

tibjms-6.0.1.jar包中com.tibco.tibjms.TibjmsConnection 中做了相关定义：
int _reconnect_attempt_count = 4;
int _reconnect_attempt_delay = 500;
int _reconnectAttemptTimeout = 0;

可以通过修改factories.conf文件或通过客户端连接工厂API设置。
JAVA代码可以使用 TibjmsConnectionFactory的setReconnAttemptCount(),setReconnAttemptDelay(),setReconnAttemptTimeout() 方法设置新的失败重连参数，例如：
factory.setReconnAttemptCount(10);
factory.setReconnAttemptDelay(1000);
factory.setReconnAttemptTimeout(1000);.