级别： 初级 娄丽军, 软件部售前工程师, IBM公司
2004 年 4 月 01 日 本文继续讲解了 Message Broker的应用开发，及其性能的调整和系统管理。
1 Message Broker应用程序设计
1.1 一般指导原则
首先我们谈一谈Message Broker应用程序设计的一些指导原则(Guidelines)。实际上，MB的应用程序就是一个MQ的应用，它也是利用MQ的API编写的一支应用程序，因此，MB应用程序首先要遵循MQ应用开发的指导原则，除此之外，要考虑如下一些主要因素：
1.1.1 消息亲合性：
当应用程序从业务需求的角度需要从逻辑意义上将多个消息作为一个完整业务来处理，或者需要保证消息被处理的顺序时，就需要保证消息亲合性。消息亲合性的要求妨碍了我们对消息的并行处理，群集功能使得MQ和MB具有很好的可扩展性，但是，消息亲合性需要多个消息被同一个线程处理，所以影响了可扩展性，并造成系统瓶颈。因此，在MB应用程序中要避免对消息亲合性的要求。例如：在某个系统中，我们需要将若干条条目组成一个定单，最简单的方法是将每一个条目作为一条MQ的消息，但是，这种做法有很大的弊端：由于多个消息才能产生一个完整的业务数据从而导致了消息亲合性，这就需要在MB的消息处理中加入组合消息的处理逻辑。在这种情况下，更好的设计方法可以将所有条目作为一条消息交由MB来处理。
另外一个消息亲合性的例子是当对消息处理的顺序有要求的情况。例如：在一个系统中我们要处理新客户的信息，并且将其增加到客户数据库中。这时可能需要处理程序在一个单线程中运行，以保证为每个新客户产生正确的客户编号，并且避免在数据库中产生重复的记录。
1.1.2 消息的永久性设置
永久性消息保证了消息在系统和网络等故障下的安全可靠，但是同时从性能角度来讲会比非永久性消息要差，因此，要从不同的角度进行权衡和分析，然后决定消息的永久性属性。当对性能要求很高，可靠性要求相对不高时，可以采用非永久性消息。例如，某个请求端应用通过MB向另一个系统发出一个查询请求，交易量为每秒3000次，在该情形中，某个消息的丢失对请求端应用的影响不是很严重，它可以重发请求，因此，我们可以使用非永久性消息。
1.1.3 消息的RFH头的使用
RFH分为版本1：RFH1和版本2：RFH2两个版本，RFH2与RFH1的结构基本相同，但是增加了对Pub/Sub的扩展支持，所谓扩展支持，是指基于内容(Content based)的Pub/Sub的功能，对这两种版本MB都支持。通常情况下，我们不需要使用RFH头，因为对每一种消息的处理我们会定义不同的消息流，而不同的消息流对应的输入队列也会不同。这样做的主要益处在于：
- 简化了发送和接收端的应用程序的编写，如果在MB中要使用RFH头，我们就必须在向MB发送消息时，为其添加RFH头，增加了应用的复杂程度；
- 不同类型的消息被不同的消息流处理便确保了每种不同的消息在MB中被不同的线程处理；
- 确保了消息类型和应用程序相对Broker的独立性，我们不需要在应用程序层来定义消息的类型。
当然，当我们使用Pub/Sub相关的功能时，我们可以在Pub/Sub应用中使用RFH头，或者在消息流中利用一个计算节点(Compute Node)来处理RFH头。
1.1.4 逻辑工作单元(Logical Units of Work)的使用
在MB中有多种方法来定义逻辑工作单元，整个消息流是不是会被作为一个全局逻辑工作单元来处理取决于消息的永久性属性设置、MQInput 节点属性的设置等多方面，如下表所示：
但是要注意的是：逻辑工作单元不能跨越多个输入消息。当一个消息流涉及到与数据库的操作时，我们可以设置该数据库操作是否参与全局逻辑工作单元，当它参与全局逻辑工作单元时，数据库操作和消息处理将遵循两阶段提交协议，这时，MQ担当XA协调器。
1.2消息流设计
MB可以使复杂的消息格式转换工作变得非常容易，在MB中创建消息流也非常容易，因此不少用户在MB中利用消息流对消息进行非常复杂的业务逻辑处理，通常这是要避免的。我们的建议是不要把Msg Flow设计得过于复杂，MB是设计用来转换和路由消息的，同时对消息进行必要的处理，它不是一个MQ的应用服务器，不是对周边的应用程序的替代。
例如，在下列场合可能效果就不是很好：
- 在一个消息流中要涉及对多个数据库的更新操作，并且所有这些操作都要在同一个逻辑工作单元完成；
- 消息流中涉及对数据库的复杂操作，尤其是通过ODBC连接对远程数据库进行该操作，在这种情况下，数据库可能会成为消息流的瓶颈；
- 需要对多个输入消息进行组合的消息流；
- 处理逻辑非常复杂的消息流，例如包含许多计算节点的消息流，设计原则是最好保证单个消息流中总节点的个数不超过30个，其中需要对消息进行复杂处理或参与逻辑工作单元的节点不超过10个。从最大限度上来说，单个消息流中的节点总数也是有限制的，一般来说不能超过500个。如果不能避免，推荐使用多个消息流来处理；
- 对消息处理顺序有要求的消息流，在消息流中加入对顺序的控制需要复杂的逻辑，这样会影响消息流的性能；
- 处理非常大消息的消息流，一般情况下，建议消息大小不超过10MB。
应用集线器的采用主要是它在系统架构上的优势，避免了应用程序点对点的直接连接，从而减少接口开发的个数，提高系统的可扩展性，降低系统间的耦合度。MB适用于对消息进行格式转换和较为简单的运算处理，但是性能要求很高的场合。我们可以将复杂的业务逻辑运算放到应用程序端处理。
1.3ESQL高级使用
对消息流的开发，最关键的是对ESQL的编写技巧，表现在对ESQL的熟悉和熟练程度，ESQL为我们提供了十分丰富的功能，实际项目中，我们要对其灵活使用，以便充分发挥其作用和效能。这里以THE、ITEM和EVAL的使用来举个简单的例子：
当我们使用SELECT语句作SQL查询时，可能会返回一个结果集，THE的作用是使SELECT语句只返回一条结果。如：
SET OutputRoot.XML.Test.Result =
THE (SELECT T.Field4,T.Structure1 FROM InputBody.Test.Input []
AS T WHERE T.Field1 ='value1')。
|
ITEM的作用可以使我们在输出结果中省略数据库的字段名称，在下例中，ESQL语句：
SET OutputRoot = InputRoot;
SET OutputRoot.XML.Test.Result[] = (SELECT T.Column1 FROM Database.USERTABLE AS T);
|
将会产生以下结果：<Test><Result><Column1>value1</Column1></Result><Result><Column1>value3</Column1></Result></Test>； 如果使用ITEM，即：SET OutputRoot.XML.Test.Result[] = (SELECT ITEM T.Column1 FROM Database.USERTABLE AS T); 则将会产生如下结果：<Test><Result>value1</Result><Result>value3</Result></Test>
EVAL的功能很强，我们可以使用EVAL来动态创建ESQL语句或表达式，例如：
SET OutputRoot.XML.Data.Result =EVAL('A'||String1 ||'B');
EVAL('SET '||scalarVar1 ||'=2;');
|
在上述语句中，String1和scalarVar1两个变量的值可以来自消息体的某个字段或者其他动态的数值，这样可以帮助我们更加灵活地构造ESQL语句。
这里我们举一个用户的实际案例，该用户的需求为：它们要将SQL语句本身放在消息体中，例如：<Msg><SQL1>SELECT SELECT T.Name FROM Database.MYTABLE AS T)</SQL1></Msg>，为了能够执行此SQL操作，并将结果输出到消息体中，我们可以使用EVAL函数，方法如下：SET OutputRoot.XML.Message.Name[]=EVAL('InputBoby.Msg.SQL1');
1.4对性能的考虑
ESQL的编写方式会影响节点的处理性能，这里列举几例，仅供参考：
1） 在使用循环处理时，注意对循环条件的判断和使用，可以用变量来预置循环条件的数值，否则每次循环都要计算循环条件，我们以CADINALITY的使用来举例说明：
CARDINALITY是我们十分常用的一个功能，它能够计算出某个数组中总的字段个数或者某个结果集中条目的总个数，如：CARDINALITY(field_reference [])。然而，它的不同用法对性能的影响也不同，这里我们从两方面举例加以说明。首先，我们建议不要将CARDINALITY写在WHITE循环之中，如：WHITE I < CARDINALITY（InputRoot.XML.A.B[]），这样将导致在每次循环时都会去计算消息体中B字段的个数，相反，我们可以在循环之外先计算出字段的总个数，写法为：
DECLARE I INTEGER;
SET TOTAL = CARDINALITY（InputRoot.XML.A.B[]）;
WHILE I< TOTAL DO
END WHILE
|
2） 另外一个例子是字段参考(Field Reference) 和CADINALITY的使用对比。对字段参考的使用也可以提高性能，例如使用如下代码：
DECLARE ref REFERENCE TO InputRoot.XML.A.B[1]
WHILE LASTMOVE(ref)
DO….
MOVE ref NEXTSIBLING Repeat Name;
End while;
|
比使用如下代码的性能要好：
WHILE I< CARDINALITY（InputRoot.XML.A.B[]）;
DO…..
END WHILE;
|
这里，我们将消息体中第一个B字段作了一个引用，并且利用LASTMOVE这个字段操作函数来实现循环次数的控制。
3）当消息流的分支很多时，采用RouteToLabel节点的方式可能比采用多个Filter节点的方式性能要好；
4）CASE语句的使用技巧，为了提高CASE语句的效率，可以将最可能的分支情况放在前面，这样，当某个分支为真时，会结束对CASE语句的判断；
5）子消息流的使用不会影响性能，为了实现节点数目众多的消息流以及提高消息流的模块化设计，我们可能会使用子消息流，由于在消息流部署的过程中，主消息流及其包含的子消息流将被合并为一个完整的流程，因此并不会影响消息流的性能；
6）尽量减少消息流中处理节点的个数，尽可能将处理放在集中的节点中处理，而不要采用很多的节点，同时每个节点的处理又非常简单；
7）MQInput节点的交易性属性设置，缺省情况下，它的交易性属性设置为Yes，表示输入消息将在同步点控制之下被处理，这样这个消息流将被作为一个完整的交易来处理，为了提高性能，最好将其设置为AUTOMATIC，这意味着根据消息的永久性来确定，对于非永久性消息，将不具有交易特性。
1.5错误处理
对于MB消息流的错误处理机制，我们一定要了解，这将有助于我们分析失败消息的最终去向。
我们知道，在消息流中出现错误时，如果在交易完整性控制之下，交易将被回滚，输入消息将被重新放入输入队列，然后被重新处理。MQInput节点负责提交或者回滚消息，它的处理过程如下：
1） 当消息从MQInput节点对应的队列中被取出，它从输出端(Out Terminal)进入后续处理节点，如果后续处理都成功，则整个消息流被提交；
2） 如果在输出端(Out Terminal)的后续处理中出现例外，并且该例外在Try-Catch节点的Try端后续节点中被捕获，则消息将被发送到Catch端处理，如果处理成功，则整个消息流被提交；
3） 如果Catch端处理失败，则整个消息流被回滚。
如果回滚次数达到了输入队列属性中定义的回滚次数的阈值，消息仍不能被正确处理，那么消息将被发送到MQInput节点的Failure端；如果没有连接Failure端，消息将被放入指定的回滚队列(Backout queue)；如果没有定义回滚队列，则消息将被放入队列管理器的死信队列；如果没有定义死信队列，则消息将被放入消息流的输入队列，从而阻碍了对后续消息的处理。因此，我们要避免最后一种情况的发生，这就需要我们定义输入队列的回滚次数阈值以及相应的回滚队列，并且可将回滚次数阈值设置得稍微小一些。
我们可以灵活地使用MB的Try-Catch节点和各个节点的Failure端连接方式来进行消息流的错误处理。
Try-Catch节点的使用：使用Try-Catch节点可以使我们有效地分析错误原因，避免只是简单地将消息流回滚。在消息被送往捕获端(Catch Terminal)时，产生的例外信息会被添加到消息的例外列表树(ExceptionList Tree)中，通过对其进行分析，我们可以得知消息出错的地点和原因；而且，当消息在被发送到捕获端时，将保持原有状态，因为在Try分支中对消息的修改都将不被进行。
Failure端的使用：许多类型的消息处理节点都具有一个Failure端，如果节点中的消息处理失败，消息将被发送到Failure端。但是在使用Failure端时必须要注意的是，对除了MQInput节点以外的其他节点的Failure端的连接可能会阻止消息流的必要回滚。例如通过对MQOutput节点的Failure端进行的处理，我们可以使得在出现错误时消息被放置到另外一个队列中。但是当消息被Failure端处理时，整个消息流被认为是处理成功的，这意味着之前对数据库的操作和对消息的处理都将被提交。
在进行错误处理时，我们要了解失败的原因从而进行相应的处理，为了了解失败原因，我们要注意对例外信息的正确处理。例如，当消息是由于消息格式无法解析而不能被消息流的MQInput节点处理时，我们可能必须要将其发送到接受这种格式消息的消息流上。当消息经由失败端(Failure Terminal)或捕获端(Catch Terminal)时，会产生例外，并且该例外信息会被添加到消息的例外列表树(ExceptionList Tree)中，在消息被输出到另外一个队列之前，我们需要将这些例外信息拷贝到消息结构中，如果我们在输出消息时没有拷贝该例外信息，则将无法获得和分析失败原因。
2 Message Broker的性能调整
MB的性能与很多因素有关，如MB运行环境的部署和配置、消息流的复杂性和多少、消息流本身的开发和设计以及Broker运行的硬件条件等都将影响其性能。下面我们从系统配置等角度谈一谈如何提高MB的处理和开发性能。
2.1与系统配置相关的性能因素
2.1.1 Broker Domain的个数
一般情况下，没有必要使用多个Broker Domain。每个Broker Domain是一个独立的实体。某些情况下，用户可能会建立多个Broker Domain，由于一个Broker Domain共享同一个CM，不同应用开发的用户会被同一个CM控制，这样，如果某个用户属于mqbrdevt组，它就对同一个CM中的所有消息流拥有权限，因此就可以修改其他应用的消息流。为了避免这种情况，就需要创建多个CM和多个Broker Domain。
2.1.2 Broker的个数
在HA环境下，我们可以利用MQ的群集功能创建一个虚拟的、逻辑的大"Hub"，它由多个队列管理器，多个Broker组成，从而进行负载均衡以提高性能。Broker个数的多少应取决于客户对性能、可靠性等方面的需求。
单个服务器上Broker的个数：
在一个服务器上运行多个Broker的性能并不比在一个Broker之内运行多个执行组的性能要好。但是，当你在一个Broker中的执行组超过8个的时候，最好考虑增加Broker的个数。
2.1.3 Broker中执行组的个数
通常情况下，多个执行组可以提高性能或将消息流分组。我们可以将相同的消息流部署到不同的执行组中，这种方法相对设置一个执行组并增加消息流运行实例的做法性能要好。每个执行组是一个独立的进程，每个消息流是运行在该进程中的一个线程，对不同的消息流采用不同的执行组来运行的方式可以避免一个执行组的失败导致整个Broker处理的故障。一般说来，在设计时最好保持单个执行组中包含的消息流个数少于10个，在单个Broker上运行的执行组的个数少于8个，要注意的是，这只是一般情况下的一个建议值，具体配置还是要根据实际情况而定。
2.1.4 其他因素
由于MB本质上而言，也是基于MQ的一个应用，因此性能很大程度上取决于底层MQ的性能，因此在作性能优化时，所有对MQ本身的性能优化手段都首先适用；另一方面，由于MB能够非常容易地实现对数据库的操作，它经常被用于此目的，这时，也要考虑对数据库的性能优化。因此在对MB进行性能调优时，首先要考虑对MQ和数据库的优化。
从产品本身的设计理念上，MB本身就支持很强的并行处理特性，这可以通过增加执行组的运行个数等方法来实现。它的性能与很多因素有关，如：消息流中的节点处理代码的编写，硬件系统的CPU处理能力和磁盘I/O的速度等等。在考虑性能时，可以注意以下一些特点：
如果你的交易量只有每秒20笔的量级，那么MB的性能就可以不作为考虑的因素，因为它完全可以胜任这种规模，如果交易量达到永久性消息每秒50笔以上，或者非永久性消息每秒200笔以上，才有必要考虑MB的性能指标；
如果采用的是永久性消息，那么最好将MQ的数据日志文件系统与MQ本身放在不同的硬盘上；
如果性能是第一考虑的要素，则建议采用非永久性消息；
MB的消息流处理性能与CPU处理关系密切，因此，可以考虑采用高处理性能的CPU。
所以，我们在上生产系统之前，一定要对此进行规划和测试，为了帮助用户更好地估算和测试系统的性能指标，IBM提供了很多非常有用的指导手册和测试报告等工具，以Support Pac的形式刊登在IBM的网站上，可供用户免费下载，如，IP03 《Capacity Planning Tool（性能规划工具）》、IH03《 Message display, test and performance utilities》（消息显示、测试和性能工具）等，大家可以使用这些资源来帮助你进行系统的规划。
2.2运行环境下的性能考虑
2.2.1 MQ的消息类型
永久性消息和非永久性消息的性能差异是非常大的，非永久性消息与CPU处理速度和内存关系更加密切，而永久性消息与磁盘I/O关系更加密切，在使用永久性消息和非永久性消息时，我们可以考虑如下因素：
对于非永久性消息：
将MQInput节点的transactionMode属性设为Automatic或者No，其缺省值为Yes；
尽量减少I/O操作，避免在一个队列中放置大量的消息或大消息。一方面保证发送端应用程序不断地向输入队列发送消息，而不是突然间将大量的消息放置到输入队列中，从而导致队列缓冲区的溢出，缺省情况下队列缓冲区的大小为64KB；另一方面确保被MB发送到输出队列中的消息能够被及时处理。
对于永久性消息：
将MQ队列管理器的数据日志放到独立的硬盘上，并采用高速I/O设备；
如果有数据库操作，将数据库日志和数据放到不同的硬盘上；
2.2.2 消息格式
除了消息类型之外，消息格式也会影响性能。当创建消息时，对消息格式有三种选择，最简单的是采用Generic XML格式，这种格式不需要预定义并且消息字段的顺序可以任意，消息被简单解析；其次是固定的MRM消息格式定义，这要求对其预先在MB中进行严格定义，包括字段的顺序、每个字段的长度等信息；还有就是BLOB类型的消息，它不需要MB解析，但是你需要在消息处理节点中对其进行解析。虽然MB的功能之一是进行格式转换，但是从性能角度而言，不同格式之间的转换工作会消耗MB的性能，因此，在允许情况下，尽可能使输入和输出采用相同的格式。
2.2.3 其它常见的考虑因素
从硬件角度而言，使用高性能的处理器，保证足够的内存大小；
如果是多处理器的系统，使用尽量多的执行组，然后根据测试情况，最后确认合适的执行组数目；
使用多个执行组，而不是采用多个消息流或者增加消息流的实例数目；
在消息流中使用尽量少的节点个数：相对使用多个节点而言，可以采用相对较少数目的、但是处理逻辑稍微复杂的Compute节点，例如：不要采用两个连续的Compute节点，而是可以将这两个节点中的处理逻辑合并到一个节点中实现；
在每个节点的处理逻辑中，注意ESQL编写对性能的影响，如：CARDINALITY的使用等；
对于有数据库参与的消息流的交易性属性的设置，只有在十分必要的情况下，再采用XA控制交易完整性设置；
MQInput节点的交易性属性设置，缺省情况下，它的交易性属性设置为Yes，表示输入消息将在同步点控制之下被处理，这样这个消息流将被作为一个完整的交易来处理，为了提高性能，最好将其设置为AUTOMATIC，这意味着根据消息的永久性来确定，对于非永久性消息不要设置其交易特性；
小心使用MQInput节点的Logical Order属性，例如：如果采用"ByUserID"将会限制消息的吞吐率，对于特定用户的消息将会被限制在同一个线程中被处理。
2.3 开发环境下的性能考虑
2.3.1 JVM Heap Size
当你部署非常大的、非常复杂的消息流到Broker的时候，可能会遇到这种情况，经过了很长时间，最后你得到一个超时提示，随后的其他操作，如：连接CM、刷新日志等也会得到超时信息，在Event Log中没有任何事件产生。这种现象可能是由于CM的JVM内存不够导致的。JVM Heap Size的缺省值为128MB，我们可以通过修改注册表的方式修改它的大小。
2.3.2 DB2 参数
对于CM来说使用的数据库必须是DB2，增大CM数据库的Database Heap Size，Application Heap Size, Application Control Heap Size, Buffer Pool Size的数值也可以提高CM的性能。
2.3.3 MQ 参数
对于大规模的系统来说，一次部署消息可能会很大，因此，必要时要增大CM和Broker所在的队列管理器、CM到Broker的传输队列、CM和Broker之间的消息通道以及SYSTEM.BROKER.* 队列所支持的消息的最大长度以及队列管理器的日志大小。
3 Message Broker的系统管理
MB的三个主要组件：Broker, CM, User Name Server都是不间断运行的，在Windows系统上它们作为操作系统的服务，在Unix系统上是守候进程。当它们启动时，会产生一个名为BipService的重要进程，对Broker, CM, User Name Server来说各有一个该进程，它的作用是监视Broker, CM, User Name Server的运行，当它们失败时将其重新启动。前面曾经提到过Broker的管理代理(AdminAgent), BipBroker就是它对应的进程，该进程的作用也非常重要，它通过MQ和CM通讯，并且管理名为DataFlowEngine的进程，DataFlowEngine是与执行组对应的进程，每一个被部署过的消息流都是该进程的一个线程。
管理代理会分解部署过程中来自CM的控制信息，将其分发到不同的执行组，并且收集各个执行组的响应信息，将这些响应信息汇总起来，返回给CM。
因此在Unix平台上，当MB运行出现问题时，我们最先要察看的是BipService和DataFlowEngine这两个进程的健康状况。
如果某个消息流导致了DataFlowEngine进程的失败，BipService进程会自动检测到并且将其重新启动。在DataFlowEngine进程失败时，任何正在运行的消息流都会失败，对于正在处理的永久性消息而言，没有提交的消息和数据库操作会被回滚，非永久性消息会被丢失。当执行组不能被重新启动时，系统日志会产生相应的信息提示，这通常是在某些特殊情况下，某些新消息流被成功部署但是却不能被正常启动造成的。这必然是由于在新消息流中存在错误，需要你仔细察看这些消息流，修正错误后重新部署。
当你需要完全删除并重新定义一个新的Broker时，要保证各项操作的正确顺序，如果你只是简单地利用命令行删除并重新定义了该Broker，那么CM将无法将其添加到拓扑网络中，原因是它认为已经有一个同名的Broker存在了。因此，正确的做法应该是首先更新CM，步骤是从Workbench中检出Topology-〉删除Broker-〉再检入Topology-〉部署Topology的更新信息-〉通过日志确认部署成功-〉删除Broker-〉重新创建Broker-〉将Broker注册到Topology中。
3.1 文件系统监控
一般情况下，MB相关的操作和文件系统无关，通常消息流的执行与CPU处理关系更加密切，除非消息流中存在大量的数据库操作节点，当数据库节点非常多并且数据库操作非常频繁和复杂时，才会有文件系统相关的问题。文件系统相关的问题还最可能来自MQ本身的永久性消息。
3.2 错误日志
3.2.1 系统错误日志
与CM部署操作等相关的管理信息将只能在CM端察看，它会显示在Workbench的Log Pane(日志栏)中。与Broker运行相关的信息，如：执行组的失败将被写入系统日志，在Unix操作系统上，将写入您指定的文件中，具体的设置方法可参见MB的安装配置文档。
3.2.2 应用程序日志
当消息流执行执行时出现错误时，消息会回滚到相应的入口节点，随着消息的一级级回退，在消息结构的ExceptionList中会记录相应的信息，在入口节点，包含ExceptionList结构的消息会被发送到失败终端（Failure Terminal），我们可以对ExceptionList进行分析处理。MB的联机文档《ESQL参考手册》中给出了ExceptionList以及利用Compute节点对其进行处理的例子，可供大家参考。
3.2.3 跟踪
跟踪是一个非常有效并且十分常用的一个分析消息流处理过程的手段，对消息流的跟踪有两种不同的类型：用户跟踪和调试跟踪。我们可以在Broker, 执行组，消息流等不同的级别上对这些组件进行跟踪。调试跟踪比用户跟踪更加详细，它给出了每个节点内部的每个执行细节，例如在Compute节点中每一句ESQL语句的执行等，因此，我们经常使用的是调试跟踪。跟踪的输出结果需要通过mqsireadlog和mqsiformatlog命令来察看。
3.3消息流部署
在部署消息流时，除了第一次必须进行完全部署之外，我们可以采用增量部署的方法，这样可以使CM向Broker发送较少的配置信息。在你最近一次部署操作结束之后，你尚未得到部署结果的响应之前，不要尝试做新的部署操作，而是应该检查是否最后一次部署出了问题。部署信息在CM和Broker之间的传递底层是要依赖于MQ的通讯的，因此，要首先察看CM和Broker之间的队列管理器的通讯是否正常，两条通道是否都运行正常。如果排除了这方面的原因，可能是由于Broker或与其相关的某个进程出现了问题，如果部署操作导致了某个执行组的失败，Broker将尝试将其重新启动，这可以通过察看Broker系统的错误日志来验证。如果最终部署失败，CM会得到部署失败的信息，这可以在Workbench的日志中察看。如果CM始终没有收到错误信息，那么可以尝试重新启动Broker并采用强制部署的方法重新进行部署操作。强制部署只能对整个Broker Domain执行，强制部署的目的是当Broker Domain的配置信息处于可疑状态时对其进行刷新操作。同时要注意的是：虽然强制部署是对整个Broker Domain执行，它只是使用处于'shared configuration'状态的信息来更新Broker。
综述：Message Broker作为IBM的一个功能强大的EAI解决方案受到越来越多用户的青睐，希望通过该系列文章大家能够更好地使用该产品，为您的企业业务集成带来更多的收益！
关于作者  | | | 娄丽军，IBM公司软件部售前工程师，1998年加入IBM公司软件部，四年来一直从事IBM通讯及业务整合中间件(WebSphere Business Integration家族)产品的技术支持工作，是软件部从事该领域技术支持时间最长的工程师之一，拥有WebSphere Business Integration相关的产品经验，这些产品包括WebSphere MQ家族的所有产品：MQSeries, MQ Integrator, MQ Workflow以及CrossWorlds等，并具有很多大型项目的支持经验，曾参与国家税务总局，人民银行清算系统、华夏银行电子联行系统、中国联通计费系统、海关与国家税务总局互连系统，以及公安部、铁道部、中信实业银行、电信等重要客户的有关项目的技术支持。 |
对本文的评价
| 
