MQ配置和编程最佳实践

　　通常情况下，我们不要求用户一定去设置消息的类型，设置消息类型的方法是在消息描述符MQMD的MsgType字段，消息类型有datagram, request, reply, report等若干种。但是为了更好地对消息进行管理，我们必要时要设定消息类型，从而对不同的消息进行处理。例如，当reply消息和report消息都被发送到同一个应答队列时，我们可以根据消息类型的不同对其进行不同的处理。

　　15. 对消息转换的设置。 

通常，当需要进行消息转换时，我们有两种方法来进行设置：一种方法是在调用MQGET时设置MQGMO_CONVERT的读取消息选项；第二种方法是将发送端通道的convert属性设置为yes。对比二者，我们推荐使用第一种方法，它的优势在于：它避免了消息通道代理程序对消息的转换，从而提高了通道的性能；其次，当一对多传输时，避免了对不同的目标系统使用不同的转换算法，而统一放在接收端进行。

　　当我们不需要进行格式转换时，使用在MQMD中将消息格式Format字段设置为MQFMT_NONE的方法来表示，MQFMT_NONE表示忽视任何格式转换。

　　16. 应用程序最好不要在MQGET和MQPUT调用时使用过大的消息缓冲区，从而减少队列管理器对内存的需求。 

　　当应用程序发出MQGET和MQPUT调用时要设定用于装载消息的数据缓冲区大小，MQ系统将据此来分配内存，如果使用过大的消息缓冲区，队列管理器就会分配较大的内存来处理这些调用，从而造成内存浪费，影响性能。如果我们在接收端不知道消息的大小，为了不至于设置一个很大的缓冲区去接收数据，我们可以在真正的MQGET之前先使用Browse方式来浏览一下队列中的消息，根据浏览到的消息的MQMD的OriginalLength字段的数值来确定消息缓冲区的大小，然后再使用MQGET真正的将消息读取出来。

　　17. 在设定消息的优先级时，不要直接在消息描述符中设置，最好设置队列的优先级，然后使用"defined as queue"来设置消息的优先级。 

　　优先级是消息的属性之一，当应用发生变化时，我们可能需要改变消息的优先级，如果我们将其写死在程序中，就会影响程序的灵活性。如果借助于队列的优先级来设置消息的优先级，系统管理员可以根据需要，通过改变队列的DEFPRTY的属性来更改其优先级，而无需改变应用程序代码，这样可以大大提高系统管理和网络管理的灵活性。

　　18. 请求型应用在打开请求队列时，最好不要使用MQOO_OUTPUT选项。 

　　请求队列可以是本地队列，也可能是远程队列，本地队列是既可读又可写的，而远程队列是只可写(MQOO_OUTPUT)的。通常，请求型应用一般都是需要将请求发送到请求队列中，对队列的操作都是MQPUT，这时，队列的类型不会有影响，因为本地队列和远程队列都是可写的。但是，如果某个请求型应用需要读取请求队列，则要求请求队列一定是本地队列，这时就不能使用MQOO_OUTPUT选项。因此建议在打开请求队列时，最好不使用MQOO_OUTPUT选项，可以使得不同的应用之间很容易移植，而且当队列属性改变时，不会对应用程序造成影响。

　　19. 与数据库交互时，MQPUT 和 MQGET必须使用同步点控制，即使用MQ的两阶段提交功能，来保证数据的一致性和完整性。 

　　为了保证数据库操作和MQ操作同时成功或同时回滚，需要在做MQPUT 和 MQGET调用时，使用MQPMO_SYNCPOINT和MQGMO_SYNCPOINT选项将队列操作和数据库操作作为一个事物来完成。这样，如果数据库出现问题导致操作失败时，消息可以被正确回滚；否则，会导致数据不一致的现象。

　　20. 与数据库操作相关的队列消息的属性最好设为永久性消息，即消息的persistence属性应设为yes，并且永不过期。 

　　由于与数据库操作相关的消息的重要性很强，它必须被设置为永久性消息，被MQ系统记录日志，从而在队列管理器重新启动或机器重启时不会丢失。另外，在 "Send and Forget"通讯模式之下，由于这是典型的异步通讯模式，消息何时被处理是不确定的，为了防止消息超时，我们应将其生命周期设置为永不过期。

　　21. 对消息做了修改或者转发的应用，最好传递原始消息的identity context(身份鉴别上下文)信息。 

　　每个MQ的消息都有其特定的鉴别上下文，通过消息描述符(MQMD)的相关字段来表示，它代表了消息是由谁产生的，当消息在MQ网络中传输时，该上下文应该必须被保留。当消息被另外的用户修改或者转发时，需要修改其上下文，将其原始的上下文重新赋进去。这主要是处于安全的考虑，通过上下文，可以获得消息产生者的信息。

　　22. 保持永久性动态队列名称的唯一性，确保同一个应用多次调用/运行产生的动态队列的名字唯一性。 

　　当应用程序需要动态产生应答队列时，它可以产生临时性动态队列和永久性动态队列，某些情况下，将利用永久性动态队列保留一些可恢复的消息，这意味着该永久性动态队列可以重新被打开，因此要保证它们名称的唯一性。

　　23. 在使用临时性动态队列来处理应答时，处理请求消息的应用要保证不要将应答消息设置为永久性消息。 

　　临时性动态队列不能存储永久性消息，鉴于此，对请求做出响应的应用程序必须知道接收应答的队列是临时性动态队列还是永久动态队列，请求端应用和响应端应用必须对响应消息的永久性进行协调，以保证只有非永久性消息会被放置到临时动态队列中。

　　结论：为了更好地使用MQ，我们必须遵循一定的标准和指导原则，使得我们开发出更加可靠、高效的应用程序，当然，这是从普遍意义上而言，在实际应用中需要您灵活掌握，因地制宜地选用更加适合您的配置和编程模式。