MQ配置和编程最佳实践

　　如果某个消息是在同步点控制之下读取的，并且由于某种原因消息被回滚，消息描述符中(Message Descriptor)的BackoutCount字段的值将被加1，你需要判断该数值，如果它大于某个阈值，你需要使用其它手段来处理该消息。否则，在某些情况下会导致读取消息-消息被回滚-再读取消息-消息再被回滚的死循环。

　　例如：你使用了触发机制设定当队列中消息到达时，触发某个应用程序，该应用程序在MQ XA Resource Manager的控制之下，读取消息，并且利用其数据对数据库进行更新，假设数据库出现问题，无法成功进行数据库操作，消息将被回滚；这时，又满足了触发条件，又会触发起该应用程序，周而复始，陷入死循环。在这种情况下，你必须在程序中加入对BackoutCount的判断。

　　5. 当处理backout消息时，可以使用队列的BOTHRESH 和 BOQNAME属性。 

　　如4 中所言，如果某个消息是在同步点控制之下读取的，并且由于某种原因消息被回滚，消息描述符中的BackoutCount字段的值将被加1，你需要判断该数值，如果它大于某个阈值，你需要使用其它手段来处理该消息。在处理该消息的应用中，你可以将其与设定的阈值做比较，这时，阈值会被写死在程序中，为了提高其灵活性，你可以使用队列的BOTHRESH 和 BOQNAME属性。这样，你可以在例外处理中，利用MQINQ查询得到阈值的大小，如果超出，可以将消息转发到BOQNAME指定的队列中，继而对该队列进行相应的处理。这种方法大大增强了应用程序的灵活性。

　　6. 在使用MQOPEN, MQPUT 和 MQGET调用时，要使用FAIL_IF_ QUIESCING的选项。 

　　MQ 系统本身和使用它提供的服务的用户应用程序之间是互相独立的，必要时，我们可能要停止MQ系统，这时，我们不但希望新的应用不能连接，并且希望所有已连接的应用能够立即停止。为了使所有的应用程序能够快速得知MQ系统正在停止的信号，在上述MQ API中，必须设置FAIL_IF_ QUIESCING的选项。

　　如果不设置FAIL_IF_ QUIESCING的选项，当MQ系统停止时，所有应用将继续运行，这样会影响MQ系统的停止，从而导致MQ停止需要很长时间，同时可能导致我们必须手工杀掉那些没有设置该选项的应用程序。

　　7. 消息描述符的不同字段的使用方法 

　　在MQ 的消息描述符MQMD中包含了很多字段，这些字段大部分是一些保留字段，例如：MsgID表示消息的唯一标识，如果你不指定，MQ系统会为你自动产生一个，并保证其唯一性；PutAppType, PutAppName, PutDate, PutTime是系统自动产生的，表示哪个应用何时将消息发送到队列中；再如：GroupId, MsgSeqNumber, Offset, MsgFlags是与消息分段和消息分组相关的控制信息；除了这些系统自动产生无法更改的字段和有特殊用途的字段之外，如果您想选择某些字段为己所用，将其设定为自己应用程序中某个有意义的标识，你可以使用CorrelId和Feedback字段，但是，按照惯例，CorrelId常常被用于在请求/应答通讯模式中来表示请求消息和应答消息之间的关联；因此，我们可以灵活使用Feedback字段，利用该字段来进行一些应用程序控制。当我们接收到某个消息之后，我们可以检查Feedback字段，根据Feedback字段值进行相应的处理。

　　8. 消息永久性属性的确定 

永久性消息保证了消息在系统和网络等故障下的安全可靠，但是同时从性能角度来讲会比非永久性消息要差，因此，要从不同的角度进行权衡和分析，然后决定消息的永久性属性。当对性能要求非常高，可靠性要求相对不高时，可以首先考虑采用非永久性消息，在消息决不允许有任何丢失，并且在丢失之后又无法重新发送时，要使用永久性消息。

　　9. 当指定消息的永久性和非永久性属性时，最好利用应用程序显式地指定，不要使用"defined as queue"的方法来指定。 

　　消息的永久性和非永久性是消息本身的属性，多数情况下，只有消息的原始发出者才了解丢失消息将产生的重大影响，因此，消息的原始发出者应在应用程序中显式地指定消息的永久性，如果将其定义为依赖于队列的该属性，就会比较被动，当队列的永久性属性(DEPSIST)被意外地设为NO时，就会有丢失的风险。

　　10. 应用程序可以将请求消息的永久性属性为No，即对于请求消息使用非永久性消息。 

　　一般情况下，请求消息丢失对应用系统不会产生严重的影响，如果出现请求消息丢失的情况，我们可以重新发送，因此，不必将请求消息设置为永久性消息。把请求消息设置为非永久性消息的另外一个好处是，系统不需要对非永久性消息记录日志，从而减少I/O操作，提高系统的性能。

　　11. 在异种操作系统平台上使用MQ传输消息时，将消息格式设置为MQFMT_STRING。 

　　MQ 的一大优势之一，是对built-in(内置的)消息格式，可以实现不同操作系统平台间、不同系统字符集之间的数据转换，如开发平台ASCII码和主机 EBCDIC码之间的转换。为了实现该数据转换，MQ必须获知本身和对方MQ系统的队列管理器的CCSID和Encoding以及消息的格式。一般而言， CCSID和Encoding会被自动设置和处理，不需要应用程序关心，但是，消息的格式必须由应用程序指定，对于MQ内置支持的消息格式，MQ可以自动转换，这些消息格式由MQFMT_*来指定。鉴于应用程序数据都可以用MQFMT_STRING来表示，并且MQFMT_STRING是MQ内置支持可以转换的格式之一，你可以使用它来表示你的消息格式，同时，对于数字型消息，你需要使用atoi, itoa等函数实现数字型和字符型之间的转换。

　　12. 对大消息的处理 

　　MQ 支持单条消息的最大长度为100M，队列管理器、队列、通道支持的最大消息的缺省值为4M，即使如此，我们却应该根据不同的网络类型和带宽，具体地确定不同情况下单条消息的合适大小。例如：如果在拨号网络或网络带宽较窄的情况下，我们将单条消息的大小设置得太大，就会影响传输效率，在这种情况下，一定要使用MQ的分段功能将消息进行分段处理，确保每一个物理消息的大小适当，MQ会自动维护整个逻辑消息的完整性，并且可以在接收端一次性将其取出。

　　13. 如何使用MQ的请求/应答通讯模式来处理同步的消息处理模式。 

　　大家知道，MQ的异步处理模式是非常强健的，同时它也支持同步的消息处理，例如MQ的client-server通讯就是一种典型的同步工作模式，对于 server-server通讯，我们也可以实现同步工作模式，这里就涉及到如何巧妙地使用MQ提供的消息生命周期的功能。这时，对于请求消息和应答消息我们最好为其设置生命周期。

　　典型的应用案例如下：假设系统A向系统B发出请求，调用B上的某个交易，这里，我们首先要设置请求消息的生命周期，并且在消息到期时将消息丢弃，如果在消息发出之前消息过期，它就会在进入通道之前，被MQ系统丢弃；如果当消息到达目的地之后，在被对方应用程序取走之前消息过期，它也将被MQ系统丢弃。系统B上的交易便不会被调起执行。对于应答消息，我们也设置它的生命周期，与请求消息不同的是，我们设置在消息到期时将其转发到另外一个特定的队列中，这时，如果系统B上的交易执行完之后，会产生应答消息，如果由于通讯等原因，该应答消息在到达系统A时应用程序设置的Timeout时间已经超出，应用程序必然认为系统B上的交易没有被执行，也不会处理该应答消息，这样，应答消息便会过期，当它过期时，根据我们的设置，它会自动被MQ系统转发到特定队列中，我们另设专门的应用程序对此进行冲正处理。