如何使用Array APV 应用交付控制器实现BEA Tuxedo 中间件的负载均衡.PDF

如何使用 Array APV 应用交付控制器 实现 BEA Tuxedo 中间件的负载均衡 随着信息技术的发展，企业的数据从分散式向集中式迁移，这样就对企业的数据中心的 可靠性有了更高的要求，对服务器的性能也有了更高的要求，单台服务器的性能已经远远不 能满足应用的要求，服务器的集群或负载均衡已经成为必然的选择。专业的负载均衡设备以 其灵活多样的负载均衡算法来实现不同类型应用的负载均衡，已经成为市场的主流选择！ 本文档主要讨论在行业客户中常见的中间件应用应该采用何种负载均衡算法的问题。 一、几种常见的中间件产品 关于中间件，有一个很有名的定义是：平台+通信。各种中间件和应用服务器产品一般 都包括一个通信子系统，这个通信子系统的目的就是接受客户机和其它服务器实例的访问。 由于应用范围和产品历史不同，这些通信子系统也就千差万别。比如 IBM MQSeries， CICS/TXSeries 和 BEA Tuxedo。 首先对比一下数据传输类中间件 MQSeries 与 TPM 类交易中间件 CICS/TXSeries 和 BEA Tuxedo。MQSeries 与 CICS/TXSeries 或 BEA Tuxedo 有很大的不同，因为 MQSeries 被设计为一个以异步数据通信为基础的中间件。MQSeries 这类中间件的特点是“存储/ 转 发”(对持久消息，直接保存到硬盘；对非持久消息，开始时先保存到共享内存)，而TPM 中间 件(包括 TXSeries 和 Tuxedo)没有这个“存储”的功能，而侧重分布式的实时交易处理。 MQSeries 的通信机制的核心是通道和收听器。通道设置决定了通信的协议、参数和相 关方法。MQSeries 的收听器有两种机制：基于 inetd 的守护进程机制(amqcrsta)，和基于线 程响应的机制(runmqlsr)。这两种机制各有优缺点。 以客户机访问方式为例，MQSeries 的每个客户机都与收听器(amqcrsta 或 runmqlsr)建 立 Socket 连接，而 MQSeries 收听器通过 IPC 机制通知 Queue Manager Agent (amqzlaa0) 读写消息和队列。客户机访问方式采用的是短连接，而通道连接方式采用的是长连接。 CICS/TXSeries 的通信处理与 MQSeries 的通道连接方式类似，使用长连接的方式。 CICS/TXSeries 的TCP/IP 收听器进程叫做 cicsip，可以看出，CICS/TXSeries 在内部使用了 一个异步处理的方式，其目的是充分利用系统资源，达到最高的吞吐效率。但对外仍然是一 个同步通信的系统。但是与 MQSeries 不同，CICS/TXSeries 没有任何存储数据或请求的操 作，队列的容量和数据的生存期也远远小于 MQSeries。 在这些方面，CICS/TXSeries 与 Tuxedo 没有什么不同。 但 Tuxedo 的通信机制还是有很多不同于 CICS/TXSeries 的方面：CICS/TXSeries 的通 信设置很简单，只须设置一个收听器 IP 和端口就可以了。Tuxedo 的通信设置可就多了，本 地语言 (C, COBOL 等)客户访问(WSL)，Java Jolt 访问(JSL)，域连接(T/DOMAIN)，集群等 等都需要独立的网络设置，使用独立的收听器。而且还有很多看不见的端口被作为客户连接 使用 (WSH) 。Tuxedo 使用短连接的方式，与 MQSeries 的客户机访问方式相似，但通信方 式要复杂一些。以本地语言客户访问的收听器 WSL 为例：WSL 在接收到客户请求后，立即 释放连接，而客户机接着使用新建的连接与一个 WSH 进程继续通信。这种方式可以降低 WSL 的工作量。 MQSeries 的通道连接方式以及 CICS/TXSeries 采用长连接的通信方式，MQSeries 的 客户机访问方式以及 tuxedo 采用短连接的通信方式。所谓长连接，就是一旦建立连接，一般 的应用API 不会中断该连接；所谓短连接，就是在一个完整的应用中先建立连接， 最后结束 该连接，而且程序退出时必然切断连接。这两种通信方式对应用系统有着深刻的影响。 长连接方式面临很对棘手的问题：客户机异常中断，网络中断，包括 Windows 9x 之类 的操作系统正常关闭，都不会通知服务器，造成服务器保持闲置无用的连接，长连接通常要 等待“