WebSphereMessageBroker开发和部署最佳实战.pdfVIP

broker:WebSphere Message Broker 开发 和部署最佳实战 疯狂代码 http://CrazyC/ ĵ http:/CrazyC/Programing/Article60118.html 　　引言 　　IBM® WebSphere® Message Broker(以下称为 Message Broker)可以作为企业服务总线使用提供用于 各种协议通用连接以及为使用结构化和非结构化数据应用提供数据转换功能 　　消息处理性能取决于很多原因包括硬件能力、软件Software配置、消息流和消息格式设计及实现以及消息 流例子数量本文将描述为众多客户带来了性能和消息流服务可用性改善实现和部署最佳实战虽然本文并不讨论 关联 WebSphere MQ 和数据库实现最佳实战但会从消息代理应用角度对其有所涉及最佳实战并不是万能在某 些情况下此处所述最佳实战需要进行修改以满足体系结构灵活性和适应客户具体需求和能力 　　最佳实战领域 　　消息流 消息流开发阶段最佳实战包括如何避免会导致性能问题消息流实现 ESQL 消息流中 ESQL 开发阶段 最佳实战包括开发可重用代码和尽可能减少消息流中优化 ESQL 代码(单从性能改善角度而言) 发布/订阅 针对 使用发布/订阅模型路由消息人员最佳实战不涉及总体最佳实战和克隆最佳实战 从 Message Broker 角度确定 WebSphere MQ 最佳实战 此部分并不描述所有相关 WebSphere MQ 最佳实战但会介绍说明在使用 Message Broker 作为 MQ 客户端应用时如何调整 WebSphere MQ 来改善性能 从 Message Broker 角度确 定数据库最佳实战 此部分并不描述所有相关数据库最佳实战但会介绍说明在使用 Message Broker 作为 MQ 客户端应用时如何调整 WebSphere MQ 来改善性能 配置 Message Broker 设置、配置和部署阶段最佳实战 不涉及特定于高可用性环境最佳实战 　　消息流 　　通常为了将配置信息同业务逻辑分离客户会将配置信息外部化到文件或数据库中此技术可能会降低性能读 取配置或参数文件是在创建节点第个例子时或处理第个消息时次性活动而不会对每个消息都进行循环检查由于 Message Broker 更多是面向 CPU 而不是 I/O通常最好尽可能避免涉及文件或数据库 I/O 操作 　　尽可能使用部分解析思路方法除非业务需要消息完整解析在消息流最后如果有输出节点(如 MQOutput)则将出现消息、转换为位流)会解析完整消息此 Message Broker 功能能帮助改进性能因此尽可能 对其加以利用 　　处理成本和消息树大小的间存在直接正比关系因此消息树大小和设计在处理成本中扮演着重要角色例如将 所有这些可能使用字段都放置在决策中以在消息开始位置路由消息由于对消息树进行部分解析时并不会完全解 析因此消息将路由到下个节点如果消息在 Header 中包含用户可维护数据文件夹(如 MQRFH2 usr 文件夹)则建 议最好在其中存储决策路由元素 　　尽可能减少消息流中节点数量还要尝试减少消息树副本或创建新消息树消息树占用了大量空间特别是在包 含大量元素情况下更是如此仅在必要时使用计算节点(提供修改树能力)的类节点以避免出现消息树副本这不仅从 内存利用率方面提高了效率而且还提高了处理速度 　　避免使用重置内容描述符 (Re Content Descriptor) 节点RCD 节点旨在用于更改实际解析完整消息树消息 域此活动内存和 CPU 使用量都较大 　　可以使用 IF 语句、“CREATE with PARSE”语句和 ESQL ASBITSTREAM 逻辑组合来消除 RCD 节点和多 个计算/筛选器节点 　　不要在生产环境中使用跟踪节点使用 ${Root} 表达式操作开销非常大这会导致进行完整消息树解析如果目 地不处于活动状态就会发生这样情况 　　在可能情况下请尽量使用用户退出并恰当地重定向审核/日志记录信息使用退出功能能够获得灵活性可在消 息处理期间动态地激活和取消激活 　　将中介结果保存在消息树中以避免在后续节点中进行重新计算如果消息在 Header 中包含用户可维护数 据文件夹(如 MQRFH2 usr 文件夹)则将中间结果存储在其中以供后续节点使用 　　当必须将消息写入到多个目地时建议使用目地列表而不要采用使用多个节点