IBM JMS 应用无法打开一个WebSphere 集群队列 - United States
JMS 应用无法打开一个WebSphere 集群队列
Technote (troubleshooting)
问题（摘要）
您有一个Java消息服务应用连接到一个为MQ集群成员的WebSphere MQ 队列管理器，但 当您的JMS应用试图去访问一个已经在集群中存在的集群队列时，却报访问失败,原因码“2085”。
当您的应用打开集群队列时，得到javax.jms.InvalidDestinationException的报错信息，具体错误为：
&MQJMS2008: failed to open MQ queue YOUR.CLUSTER.QUEUE&. The linked exception is &com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2085&.
如果MQ 版本为V7.0以后，报错信息还会包含更详细信息：
&com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2085' ('MQRC_UNKNOWN_OBJECT_NAME').&
您可能还会看到报错信息JMSWMQ2008等
当您的应用打开的JMS队列对象如果包含&Base queue manager name&值，则WebSphere MQ将只会在应用连接的队列管理器寻找队列，如果本地队列管理器器没有集群队列的本地实例，就会报“2085”错。
将您应用使用的JMS 的队列对象的Base queue manager name值移除，这样WebSphere MQ就会在集群范围内查找集群队列，不会只在本地队列管理器范围查找。您可以使用WebSphere MQ explorer，或者JMSAdmin的命令行进行修改，如果JMS应用运行在WAS中, 也可以使用WebSphere Application Server的管理控制台进行修改。
Document information
More support for:
Clustering
Software version:
7.0.2, 7.1, 7.5
Operating system(s):
Platform Independent, Windows
Software edition:
All Editions
Reference #:
Modified date:
27 December 2013
Contact and feedback
Need support?
1-800-IBM-7378 (USA)developerWorks 社区
本文通过一个分布式 MQ 集群的场景，介绍在 IoT 和 Mobile 解决方案中，如何搭建使用 Websphere MQ 集群，解决在大规模接入客户端连接的情况下，使用 MQTT 协议连接客户端和 MQ 服务器，同时介绍如何在开放平台 MQ 上配置 MQ Telemetry 服务并且发送消息到 MQTT 客户端，以及 MQTT 消息和 MQ 队列消息的存储映射的关系。
, 软件工程师,
唐子涵，IBM 中国开发中心软件工程师，从事 MQ 及 MQTT 相关开发工作。曾从事 web 项目开发和测试工作，对 Web 项目开发及 Dojo 相关技术有丰富的经验。
, WebSphere MQ for z/OS 主机团队高级软件工程师, IBM
许可，自从 IBM 中国开发中心 2011 年成立 WebSphere MQ for z/OS 团队以来，一直从事主机 WebSphere MQ 集成环境测试和系统测试工作，并为客户提供支持，解决方案设计等。
, 高级软件开发工程师, IBM
向荣，是中国软件实验室（CSDL BJ）WebSphere MQTT 的一名高级软件开发工程师，之前，从事 WebSphere Adapter for Oracle E-Business Suite 的开发和测试工作。专注于 Oracle E-Business Suite 的各种接口的企业信息系统（EIS）间的业务整合。目前，从事 WebSphere MQ Telemetry 的开发和测试工作。专注于物联网（IOT）连通解决方案。
引言物联网，即 Internet of Things, 简称 IoT。它是在互联网基础上的延伸和扩展的网络，用户端从传统的计算机延伸和扩展到了任何物品与物品之间，物品通过嵌入的传感器进行信息采集，然后通过小型计算设备进行网络信息交换与通信。物联网技术是当前的技术热点，在能源、电子信息、医疗、交通、零售、物流、工业制造等行业都有相当良好的应用前景。在物联网中，MQTT 协议与相关产品负责把数据由传感器有效的传送到服务器，完成在受限、不稳定网络到因特网或企业网络的连接，实现两者互联互通。在此基础上，互通的物品不仅能通过设备采集信息、实现智能的感知，更能结合先进的信息处理、数据挖掘、人工智能等技术手段，与业务应用整合，实现从后台到前端设备的智能监控，完成进一步的信息化工作。但是，在大规模物联网建设中，服务器面对各种挑战，如大并发下多客户端的接入能力，大并发客户端接入下的消息处理能力。这种情况下，我们必然会考虑到使用集群解决 MQTT 服务器端的问题。本文将介绍如何使用 WebSphere MQ 搭建 MQTT 服务的集群。MQTT 协议简介WebSphere MQ Telemetry Transport (MQTT)
是一项专为受限设备和受限网络设计的异步消息通信协议，以轻量、精简、开放和易于实现为主要特点。在智慧的地球三个主要概念的“物连化”中，MQTT 扮演重要的角色。随着物联网中的接入设备越来越来多，从处理能力只有 8bit/ 位的芯片到以 Android 或 iOS 为操作系统的智能手机，加上网络带宽和稳定性参差不齐的现状，对物联网中的传输协议提出了巨大的挑战。MQTT 协议为解决物联网传输中的问题，具有以下功能特点：
MQTT 规范是开放并且免版税使用的，这有助于更好地推广
提供开源的实现，在 上有各种客户端的开源实现
发布 - 订阅的消息通信协议，允许一条消息只发布一次，便可被多个消费端（应用程序 / 设备）所接收
提供多种消息服务质量，包括 MQ 的黄金准则 -- 保证传递且仅有一次传递
0 ：消息最多被传递一次
1 ：消息会被传递但可能会重复传递
2 ：消息保证传递且仅有一次传递
为受限的设备所设计 :
预期客户端应用程序 / 设备有可能仅具备非常有限的处理能力和资源
占用空间极小的 MQTT 客户端 ( 和服务器 ) 类库
易于使用（和实现）
简单的动词集合，包括 connect, publish, subscribe 和 disconnect
内建结构支持处理客户端和服务器之间的连接丢失
如果客户端意外掉线，使用“遗愿和遗嘱”发布一条消息WebSphere MQ Telemetry 简介WebSphere(R) MQ Telemetry 由 Telemetry 服务和 Telemetry 客户端组成。其中 Telemetry 服务作为 Queue Manager 的一部分，可作为 MQTT 连接的服务器，Telemetry 客户端可用来测试 MQTT 连接的可用性。图 1 WebSphere MQ Telemetry 在物联网中的架构图WebSphere MQ Telemetry 作为 MQTT 协议的服务器，具有以下特点：
高度可扩展
单个 MQ 队列管理器能处理 10 万个以上并发连接的支持 MQTT 的设备 / 应用程序，并能提供极高的消息速率。
提供丰富的安全性
使用 SSL 提供的认证和加密来保证传输层的安全性
通过 JAAS 接口提供的身份认证
快速的启动和运行
有状态和无状态的会话
提供基本客户端的丰富集合
基本客户端必须连接至服务器以收发消息
与 MQ Telemetry 一并提供
从设备端的直接连通性
极小的体积 30kb C, 100kb Java
能随应用程序 / 设备重新分布部署MQ 集群在传统的开放平台 WebSphere MQ 应用架构中，每个队列管理器都是独立的。当一个 QM 给另一个 QM 发送消息时，需要定义一个传输队列（transmission queue）, 一个连接到目的端 QM 的通道，并且需要在发送消息的客户端上定义远程队列定义（remote queue definition）。为了简化 MQ 系统配置，可以通过 MQ 集群的使用，减少队列管理器上的对象数量，使得不同的 QM 可以互相通信而不需要定义众多的传输队列、通道以及远程队列定义。当集群中含有一个以上的同一队列实例时，WebSphere(R) MQ 会根据负载均衡算法选择最佳的队列进行消息路由。集群组成部分存储仓库（repository）：存储仓库包含集群中队列管理器的基本信息。
完全存储仓库（full respository）：保存该集群中所有队列管理器的基本信息的队列管理器，称为该集群的完全存储仓库。
部分存储仓库（partial repository）：只保存和自己有关的队列管理器（有消息交换关系）的信息的队列管理器，称为该集群的部分存储仓库。当部分存储仓库的队列管理器需要知道集群中其他队列管理器信息时，向完全存储仓库发送请求，并更新自身的部分存储仓库。队列管理器使用 MAND.QUEUE请求并接收来自完全存储仓库的更新。集群队列（cluster queue）：集群队列是在集群中的一个 QM 上定义的本地队列（local queue），并且通过广播，使集群中的其他队列管理器可以向该队列存放消息。集群通道（cluster channel）：在集群中需要定义 cluster-receiver 和 cluster-sender 通道，只有在一条通道的两端分别定义 cluster-sender 和 cluster-receiver 之后，通道才能被启动。当集群中的 QM 需要互相通信时，WebSphere(R) MQ 会根据初始化定义的通道和集群拓扑结构，自动定义 cluster-sender 通道。集群主题（cluster topic）：集群主题是用 cluster 关键字定义的主题对象。在一个队列管理器上定义集群主题后，完全存储仓库会将集群主题的定义广播到集群中的所有队列管理器，使得集群中连接到所有队列管理器的发布者和订阅者都能使用这个集群主题。但是，对该主题的修改，只能在定义主题的队列管理器上进行。MQ Telemetry 与队列管理器的整合MQTT 客户端作为一个发布 / 订阅的应用整合在 WebSphere MQ 中，可以在 WebSphere MQ 中发布、订阅主题，创建新主题或使用已有的主题。在 WebSphere MQ 中，发布 / 订阅引擎会将 MQTT 客户端创建的主题映射到已存在的主题对象上，主题字符串将被映射到最近的父级主题中，如果用户未创建该主题对象，发布的主题会被映射到 SYSTEM.BASE.TOPIC。当 WebSphere MQ 应用创建一个主题订阅时，该订阅对象即被命名，但作为 MQTT 客户端则不同，所有 MQTT 的订阅对象都按照既定格式命名，以 client ID 和 主题字符串组成，即：ClientIdentifier:Topic name。WebSphere MQ 的应用程序也可以发布 MQTT v3 的消息到 MQTT 客户端订阅的主题中，发布的消息默认存在 SYSTEM.MQTT.TRANSMIT.QUEUE中，由 MQXR 服务发送到客户端。通过在 WebSphere MQ 中，MQTT 客户端发布的 Retained 消息，默认存储在 SYSTEM.RETAINED.PUB.QUEUE中。搭建 Websphere MQ 集群测试场景在本次测试场景中，搭建由四个队列管理器组成的 MQ 集群，其中包含两个完全存储仓库和两个部分存储仓库，完全存储仓库负责保存备份集群中队列管理器的基本信息，部分存储仓库做业务应用。图 2 测试集群示意图在上图中，FULL_QM1 和 FULL_QM2 作为完全存储仓库，PART_QM1 和 PART_QM2 作为部分存储仓库。创建集群清单 1 创建队列管理器FULL_QM1.DLQ FULL_QM1
strmqm FULL_QM1
runmqsc FULL_QM1
DEFINE LISTENER ('LISTENER.TCP') TRPTYPE (TCP) PORT (5000) CONTROL (QMGR)
START LISTENER ('LISTENER.TCP')
END清单 1 中，用 crtmqm 命令创建了名为 FULL_QM1 的队列管理器。命令中的其他参数：
-h 表示一个应用程序可以 MQOPEN 的最大句柄数 min=1,max=,default=256
-lp 表示主 log 文件数 min=2,max=62,default=3
-ls 表示备用 log 文件数 min=1,max=61,default=2
-u 表示死信队列，FULL_QM1.DLQ 死信队列名称，FULL_QM1 队列管理器名称。在 runmqsc 中，创建并启动端口为 5000 的 Listener，以及类型为 SVRCONN 的通道。用同样的方式，分别创建图 1 中的其他队列管理器：PART_QM1，FULL_QM2，PART_QM2。端口分别为 01。清单 2 创建队列管理器crtmqm -h 1024 -lp 20 -ls 10 -u PART_QM1.DLQ PART_QM1
strmqm PART_QM1
runmqsc PART_QM1
DEFINE LISTENER ('LISTENER.TCP') TRPTYPE (TCP) PORT (5001) CONTROL (QMGR)
START LISTENER ('LISTENER.TCP')
DEFINE CHANNEL ('SYSTEM.ADMIN.SVRCONN') CHLTYPE (SVRCONN)
crtmqm -h 1024 -lp 20 -ls 10 -u FULL_QM2.DLQ FULL_QM2
strmqm FULL_QM2
runmqsc FULL_QM2
DEFINE LISTENER ('LISTENER.TCP') TRPTYPE (TCP) PORT (4000) CONTROL (QMGR)
START LISTENER ('LISTENER.TCP')
DEFINE CHANNEL ('SYSTEM.ADMIN.SVRCONN') CHLTYPE (SVRCONN)
crtmqm -h 1024 -lp 20 -ls 10 -u PART_QM2.DLQ PART_QM2
strmqm PART_QM2
runmqsc PART_QM2
DEFINE LISTENER ('LISTENER.TCP') TRPTYPE (TCP) PORT (4001) CONTROL (QMGR)
START LISTENER ('LISTENER.TCP')
DEFINE CHANNEL ('SYSTEM.ADMIN.SVRCONN') CHLTYPE (SVRCONN)
END接下来，将队列管理器 FULL_QM1 , FULL_QM2 添加到集群（NEW_CLUSTER）中，作为完全存储仓库。清单 3 添加完全存储仓库ALTER QMGR REPOS ('NEW_CLUSTER')
runmqsc FULL_QM2
ALTER QMGR REPOS ('NEW_CLUSTER')
END两个完全存储仓库之间需要接收通道和发送通道，每个部分存储仓库连接到一个完全存储仓库的发送和接收通道，以实现集群中消息的路由。清单 4 创建发送和接收通道runmqsc FULL_QM1
DEFINE CHANNEL ('TO.FULL_QM1') CHLTYPE (CLUSRCVR) TRPTYPE (TCP)
CONNAME('localhost(5000)') DISCINT(0) CLUSTER ('NEW_CLUSTER')
DEFINE CHANNEL ('TO.FULL_QM2') CHLTYPE (CLUSSDR) TRPTYPE (TCP)
CONNAME('localhost(4000)') DISCINT(0) CLUSTER ('NEW_CLUSTER')
runmqsc PART_QM1
DEFINE CHANNEL ('TO.PART_QM1') CHLTYPE (CLUSRCVR) TRPTYPE (TCP)
CONNAME('localhost(5001)') DISCINT(0) CLUSTER ('NEW_CLUSTER')
DEFINE CHANNEL ('TO.FULL_QM1') CHLTYPE (CLUSSDR) TRPTYPE (TCP)
CONNAME('localhost(5000)') DISCINT(0) CLUSTER ('NEW_CLUSTER')
runmqsc FULL_QM2
DEFINE CHANNEL ('TO.FULL_QM2') CHLTYPE (CLUSRCVR) TRPTYPE (TCP)
CONNAME('localhost(4000)') DISCINT(0) CLUSTER ('NEW_CLUSTER')
DEFINE CHANNEL ('TO.FULL_QM1') CHLTYPE (CLUSSDR) TRPTYPE (TCP)
CONNAME('localhost(5000)') DISCINT(0) CLUSTER ('NEW_CLUSTER')
DEFINE CHANNEL ('TO.PART_QM2') CHLTYPE (CLUSRCVR) TRPTYPE (TCP)
CONNAME('localhost(4001)') DISCINT(0) CLUSTER ('NEW_CLUSTER')
DEFINE CHANNEL ('TO.FULL_QM2') CHLTYPE (CLUSSDR) TRPTYPE (TCP)
CONNAME('localhost(4000)') DISCINT(0) CLUSTER ('NEW_CLUSTER')
END通过以上步骤，完成了图 2 中集群的配置步骤。然后，需要在 MQ Explorer 中激活 WebSphere MQ Telemetry 服务及配置。图 3 启动 MQ Telemetry 服务点击‘ Define Sample configuration ’设置 MQ Telemetry。图 4 设置 MQ Telemetry下面，在完全存储仓库中添加集群主题后，就可以实现以该集群作为 MQTT 的服务器，客户端可以通过连接到集群中的任何一个队列管理器，订阅和发布消息到这个集群主题。清单 5 创建集群主题runmqsc FULL_QM1
DEFINE TOPIC('MQTTExampleTopic') TOPICSTR('/MQTTExample') CLUSTER(NEW_CLUSTER) REPLACE创建完集群后，可以在 MQ Explorer 中的 Queue Manager Clusters 选项卡中，看到所有集群的信息。图 5 WebSphere MQ Explorer 中的集群信息在 Full Repositories（完全存储仓库）中，点击 FULL_QM1 查看集群队列管理器信息。图 6 WebSphere MQ Explorer 中显示的完全存储仓库的集群主题图 6 中的 Cluster Topics（集群主题）选项卡显示了在清单 5 中创建的集群主题信息。通过 MQ 集群功能，集群主题可以在集群中的任何一个队列管理器上创建，在集群中的其他队列管理器上共享，打开 FULL_QM2, PART_QM1, PART_QM2, 可以看到相同的集群主题信息。打开 Cluster-sender Channels（集群发送通道）选显卡，可以看到在清单 4 中创建的发送通道，以及集群自动生成的发送通道。图 7 WebSphere MQ Explorer 中显示的完全存储仓库的发送通道打开 Cluster-receiver Channels（集群接收通道），查看集群中队列管理器上的接收通道。通过以上步骤，已经建立并检查了创建的 NEW_CLUSTER 集群，包含两个完全存储仓库和两个不完全存储仓库。下面，我们在具体的业务场景中，测试集群对 MQTT 服务的支持。功能测试在 NEW_CLUSTER 集群中，创建了主题字符串为“/MQTTExample”的主题对象，下面，分别用两个客户端分别连接至 PART_QM1 和 PART_QM2，并订阅发布到“/MQTTExample”主题，通过集群的消息路由功能，对不同队列管理器的实现消息的共享，MQTT Telemetry 充分利用 WebSphere MQ 集群的负载均衡的优势。在 MQ Explorer 中，启动两个 MQTT Utility（MQTT 测试工具），用 client ID 分别为 client1 和 client2 的客户端，连接到 PART_QM1 和 PART_QM2 的 MQTT 通道，端口分别为 1886 和 1887。MQTT 服务通道的端口可以在启动 MQ Telemetry 服务时设置（图 3、4），也可以之后修改。图 8 功能测试左图中，client1 订阅“/MQTTExample”，client2 发布消息到“/MQTTExample”主题，client1 的历史记录中可以看到 client2 发布的消息。在 MQ 集群中使用 MQ Telemetry 的注意事项在 WebSphere MQ 中使用 MQ Telemetry 的注意事项及最佳实践总结如下：
MQ 集群中的完全存储仓库存储集群中队列管理器的元数据信息，一个集群不建议使用超过两个完全存储仓库
完全存储仓库建议不做业务应用，具体业务应用使用不完全存储仓库
在 MQ 集群中使用 MQTT Telemetry 服务时，只需要在集群中建立集群主题（Cluster Topic），并且只需要在集群中的一个队列管理器创建，不需要创建共享队列，默认使用 SYSTEM.MQTT.TRANSMIT.QUEUE
使用 MQ Telemetry 不需要手动创建订阅对象（Subscriptions），MQXR 服务默认使用 client ID :topic string 为名字自动创建订阅对象总结本文介绍如何搭建 WebSphere MQ 集群，以及集群与 MQTT Telemetry 功能的整合，充分利用了集群的负载均衡功能，通过集群的消息路由，对不同队列管理器的实现消息的共享，利用集群的优势，实现在已有架构基础上，扩展 MQTT 客户端的规模。
参考资料 信息中心在发布订阅场景中的性能调优集群进行负载平衡提供安全的物联网连接解决方案产品协议规范访问 developerWorks ，了解关于信息管理的更多信息，获取技术文档、how-to 文章、培训、下载、产品信息以及其他资源。加入 。查看开发人员推动的博客、论坛、组和维基，并与其他 developerWorks 用户交流。
developerWorks: 登录
标有星（*）号的字段是必填字段。
保持登录。
单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件。
在您首次登录 developerWorks 时，会为您创建一份个人概要。您的个人概要中的信息（您的姓名、国家/地区，以及公司名称）是公开显示的，而且会随着您发布的任何内容一起显示，除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。
所有提交的信息确保安全。
选择您的昵称
当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。
您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。
标有星（*）号的字段是必填字段。
(昵称长度在 3 至 31 个字符之间)
单击提交则表示您同意developerWorks 的条款和条件。 .
所有提交的信息确保安全。
文章、教程、演示，帮助您构建、部署和管理云应用。
立即加入来自 IBM 的专业 IT 社交网络。
免费下载、试用软件产品，构建应用并提升技能。
static.content.url=/developerworks/js/artrating/SITE_ID=10Zone=WebSphereArticleID=1013585ArticleTitle=使用 WebSphere MQ 搭建 MQTT 服务的集群publish-date=&ihs+websphere多集群+多端口web服务器架构
秒后自动跳转到登录页
(奖励5下载豆)
快捷登录：
举报类型：
不规范：上传重复资源
不规范：标题与实际内容不符
不规范：资源无法下载或使用
其他不规范行为
违规：资源涉及侵权
违规：含有危害国家安全等内容
违规：含有反动/色情等内容
违规：广告内容
详细原因：
任何违反下载中心规定的资源，欢迎Down友监督举报，第一举报人可获5-10下载豆奖励。
视频课程推荐
ihs+websphere多集群+多端口web服务器架构
上传时间：
技术分类：
资源评价：
（5位用户参与评价）
已被下载&29&次
日前本人做为一个项目的外援参与配置了一个复杂WAS群集架构的部署，该项目由于遇到特殊情况需求采用HIS＋WAS6ND实现多应用服务器集群＋多web端口服务器架构，在Google上搜索了一遍，没有找到类似的架构配置方式，只有自己来研究了。总算功夫不负有心人，经过多次实验，终于成功实现了上述架构的配置。由于配置过程中经历了种种艰辛，所以将这种架构的配置经验做了总结，与大家分享，希望能对大家有所帮助。
（5位用户参与评价）
down友评价
51CTO下载中心常见问题：
1.如何获得下载豆？
1)上传资料
2)评论资料
3)每天在首页签到领取
4)购买VIP会员服务，无需下载豆下载资源
5)更多途径：点击此处
2.如何删除自己的资料？
下载资料意味着您已同意遵守以下协议：
1.资料的所有权益归上传用户所有
2.未经权益所有人同意，不得将资料中的内容挪作商业或盈利用途
3.51CTO下载中心仅提供资料交流平台，并不对任何资料负责
4.本站资料中如有侵权或不适当内容，请邮件与我们联系（）
5.本站不保证资源的准确性、安全性和完整性, 同时也不承担用户因使用这些资料对自己和他人造成任何形式的伤害或损失
下载1566次
下载1510次
下载2423次
下载2335次
下载1543次
下载1186次
下载1395次
相关专题推荐
磁盘阵列简称RAID，有“价格便宜且多
网络存储系统的搭建能够为我们带来极
VMware是提供一套虚拟机解决方案的软
从开发、测试、生产三部曲这样的运作
本专题为vmware中文视频教程，在线视
本专题介绍了weblogic服务器在企业应
Vmware View是Vmware的桌面和应用虚拟
vSphere不是一个单独的产品，它由一系
本专题全面深入讲解Windows Server 2
本专题收集了高俊峰老师讲解的系统集
IBM TSM 备份软件实战教学视频，包含
菜鸟腾飞安全网VIP_精通VMware虚拟机
2013年传智播客WebService视频教程，
Active Directory 实操作参考系列，本
服务器虚拟化技术以VMware公司的vSph
LoadRunner，是一种预测系统行为和性
意见或建议：
联系方式：
您已提交成功！感谢您的宝贵意见，我们会尽快处理Websphere 集群 Session 内存到内存复制 -
- ITeye技术网站
HTTP 协议本身是“连接 - 请求 - 应答 - 关闭连接”的模式，是一种无状态协议；然而随着 web 动态化的需求，我们往往需要把两次连续的请求关联起来，从而使得客户端和服务端的会话变得有状态。Session 就是满足这种需求的一种实现方式。
它的基本原理是服务器端为每一个 session 管理一份会话信息数据。而客户端和服务器端依靠一个全局唯一标示符 —— sessionID 来访问会话信息数据。当用户访问 web 应用时，服务器端会先检查客户端的请求里是否包含 sessionID，如果没有或者检索不到，服务器端会自动创建一个新的 sessionID，同时开辟数据存储空间， 并且在本次响应中将 sessionID 返回给客户端保存。
当服务器端需要开辟数据存储空间时， 一般会在内存中创建相应的数据结构，但在访问量非常大的系统中，session 会占用大量的内存空间，而且系统一旦宕掉或者掉电，所有的会话数据就会丢失，这种事故在电子商务网站中会造成严重的后果。当然也可以将 session 内容存储在数据库中，从而在某种程度上实现持久化，但是这样会增加 I/O 开销，影响系统的性能。
在 IBM Websphere Application Server 中提供了两种不同的 session 持久化管理方案，如图 1 所示，分别是
1.使用数据库做 session 持久化管理
所有的 session 信息被集中存放于数据库中.2.内存到内存的复制
所有 session 的信息会存放在各个应用服务器的内存中.
图 1. session 持久化管理方案
使用数据库存储 session 数据时需要对存储的信息作序列化操作，在某种程度上影响了响应的时间和效率，适用于 session 数据量大，并且对持久化要求比较高的应用场景。在内存到内存的复制方案里，session 管理者可以把最近经常使用的 session 保存在内存里面，极大地降低了获取 session 数据的时间开销，从而满足了对效率和响应时间要求高的应用需求。从内存到内存的 session 复制，一般适用于 session 数据量不大的应用场景。本文将详细介绍内存到内存复制的持久化管理方案。
内存到内存复制
内存到内存的 session 复制指的是将 sessions 复制到另一个 WebSphere Application Server 上。在这个模式下，sessions 可以被复制到一个或者多个应用服务器上，从而防止 HTTP Session 单点失败（single point of failure）的发生。
Session 复制的目的，是将 session 的信息进行备份保存，以便在服务器发生故障的情况下，session 状态不会丢失，实现 session 的高可用性，从而保证即使有故障发生，也不会影响到客户正在进行的业务，避免造成损失，进而提高客户满意度。
目前 WebSphere Application Server 提供了三种复制方式（如图 2 所示）：
仅服务器模式： 所谓仅服务器，指的是该应用服务器只会存储其他应用服务器的 session 备份，而不会把自己创建的 session 分发并复制到其他应用服务器上。
仅客户机模式： 所谓仅客户机，指的是该应用服务器只会把自身的 session 分发并复制到其他应用服务器上，但不会存储其他应用服务器的 session 备份。
客户机和服务器模式： 所谓客户机和服务器，指的是该应用服务器既能作为服务器存储其他应用服务器的 session 备份，也能作为客户机把自身的 session 分发并复制到其他应用服务器上。
图 2. session 复制模式
WebSphere Application Server 默认的是客户机和服务器模式。用户也可以根据需要选择合适的复制模式。目前 WebSphere Application Server 支持两种 session 复制拓扑结构，分别为：
客户机 / 服务器 (Client/Server)
点对点 (Peer-to-Peer)
针对这两种拓扑结构，我们将在余下的章节中作详细的介绍。
首先，内存到内存复制功能是通过应用服务器上的数据复制服务实例来实现的，我们要确保这些数据复制服务实例是属于同一个复制域的，否则这些实例相互间就不能进行复制，从而影响内存到内存复制功能的实现。
如图 3 所示 , 复制域 Domain1 包含三个成员 Server1，Server2 和 Server3，因此这三个 server 之间能相互进行复制。但是由于 Server4 并不属于复制域 Domain1 里面的成员，因此 Server4 上的 session 不能复制到复制域 Domain1 的成员上，同时也不能备份 Domain1 上成员的 session 信息。
图 3. session 复制域
其次，属于同一个复制域的所有会话复制都必须具有相同的拓扑结构。如果同一个复制域中的一个会话管理实例使用的是客户机 / 服务器拓扑结构，则其余所有的会话管理实例只能是“仅服务器”模式或者“仅客户机”模式。相反，如果有一个会话管理实例使用的是点对点的拓扑结构，则其余 所有的会话管理实例只能被配置成“客户机和服务器”模式。“仅服务器”模式或者“仅客户机”模式不能与“客户机和服务器”模式共存于同一个复制域里面。
在集群环境中，默认采用的是点对点的单备份复制，但是我们也可以在复制域里面修改复制的数量。如图 4 所示，如果副本数选择单个副本，那么 session 只会被备份到一个复制域成员上，如果选择整个域，则 session 就会备份到所有其他复制域成员。当然，我们也可以根据实际需要来指定复制的副本数目。
图 4. 复制域配置
内存到内存复制拓扑结构：点对点
图 5 是一个点对点复制的拓扑结构图。在这个结构图中，每一个复制域成员都把 session 的信息保存在自己的内存中。同时它也会把 session 的备份信息发送并保存到其他复制域成员上，同时，它也从其他的复制域成员上获取 session 的信息。在这种情况下，每个复制域成员既可以作为一个客户端，从其他的复制域成员上获取 session 的信息；也可以作为服务端，把自身 session 的信息存储到其他复制域成员上。也就是说，每个复制域成员的复制模式都是“客户机和服务器”。
图 5. 点对点复制的拓扑结构图
在这种配置方式下，不同的服务端之间的关系是平等的，而且需要最少的服务器进程，因此它代表了最牢固的拓扑结构。尤其当各个节点具有相同的性能（CPU，内存等等）和处理相同数量的工作时，该拓扑结构可以达到最稳定的实施。
点对点复制的拓扑结构的优势是不需要额外的进程和产品来避免单点失败，从而减少了配置和维持额外进程或产品的时间和费用的成本。但这个拓 扑结构的局限性就是它需要占用一定的内存空间，因为每个服务端都需要备份这个复制域里所有 session 的信息。假如一个 session 需要 10KB 的空间来存储信息，那么当 100 万个用户同时登陆到这个系统中时，每个应用服务器就需要花费 10GB 的内存空间来保存所有 session 的信息。它的另一个局限性是每一个 session 信息的修改都会被复制到其他所有的应用服务器上，这极大地影响了整个系统的性能。
在 Websphere Application Server V7 开始支持 session 热故障恢复 (session hot failover) 功能。这个功能只适用于点到点复制模式。在集群环境中，session affinity 会把客户的所有后续请求分发到同一台应用服务器上。启用这一特性之后，如果运行某个实例的服务端突然宕掉，那么 Websphere Application Server plug-in 就会把其后续请求转发到集群环境中其他合适的服务端上。
对于设置成点到点复制模式的集群来说，这个新特性可以触发插件程序，从而让保存这些 session 备份的复制域成员来直接接管宕掉的复制域成员的工作，这样可以减少从另一个复制域成员那里再次获取 session 备份的开销。
内存到内存复制拓扑结构：客户机 / 服务器
“客户机 / 服务器”拓扑就是把集群中的复制域成员分别设置成“仅服务器”模式或者“仅客户机”模式。这种拓扑可以把备份数据和本地数据分离开来，所有“仅客户机”成 员共享“仅服务器”成员上 session 备份，减少了单个复制域成员的复制开销。拿“仅客户机”成员来说，它就不用再负责为别的成员进行 session 备份，可以有更多的资源来运行业务；而对于“仅服务器”成员来说，它只负责备份 session，不需要处理业务，其上不需要部署任何应用程序。
图 6 描述的就是“客户机 / 服务器”拓扑结构。
图 6. 客户机 / 服务器复制的拓扑结构图
这种拓扑结构的优势是它明确区分了客户机和服务器的角色。“仅服务器”成员将所有的 session 信息保存在内存中，而“仅客户机”成员专门处理业务。这样可以减少每个客户机的内存开销和性能影响。
所有“仅客户机”成员可以共享“仅服务器”成员，当有“仅服务器”成员且数据有多余两个以上的备份时，就可以实现故障恢复的目的。
在实际操作中，我们推荐使用多个备份服务器从而减少单点错误的发生。
两种复制拓扑的比较
在前面两个章节中，我们分别介绍了点到点和客户机 / 服务器两种复制拓扑结构的原理及其优势和局限性，在本章节中，我们将进一步比较这两种复制拓扑。
客户机 / 服务器
通常来说，使用这种方式，是为了在 session 副职的情况下更好地保持 session affinity。在这种拓扑结构中，
一部分复制域成员叫做客户机，其上运行的是产生 HTTP session 的 web 应用，当 session 创建或者更新时，被复制出去。
另一部分复制域成员叫做服务器，上面没有部署 web 应用，但是它的 session 管理器接收从客户机来的 session 信息，并对其进行备份。
缺省设置。每个复制域成员可以：
部署使用 HTTP session 的 web 应用
分发 session 信息给其他成员
接收其他复制域成员发来的 session 备份
每个复制域成员的复制方式，要么是“仅服务器”，要么是“仅客户机”。
所有复制域成员的复制方式是“客户机和服务器”
复制域中各节点复制功能
每一个复制域成员，要么仅作为服务器，只为别的成员存储 session 备份，要么仅作为客户机，把自己的 session 发到服务器段进行备份。
每一个复制域成员既把自己的 session 发给其他所有成员进行备份，同时又为其他所有成员备份 session。
复制的方向性
成员到成员的 session 复制是单向的
成员到成员的 session 复制是双向的
需要额外的服务器单独作为复制服务器。需要先启动所有复制服务器，在启动复制客户机，这样才能保证客户机上的所有 session 都被成功复制到服务器上。
某一时刻，每个复制域中必须至少有两个活动的复制域成员，才能保证 session 的点对点复制正常进行。如果成员只有 1 个，没法进行点对店的复制。
Session 问题诊断
在实际应用中，管理员可以通过启动 DebugSessionCrossover 来查看每个复制域成员上 session 的信息，可以查看到该成员上针对每个应用的 session 统计信息。启动该功能的步骤如下：
点击 服务器 & 应用程序服务器 & 《服务器名字》 & Web 容器设置 & Web 容器 & 定制属性 & 新建
在相应的属性里填写如图 7 所示的值，然后点击确定。
图 7. 启动 DebugSessionCrossover 检测
通过启动该功能，管理员就可以通过访问 URL：http://&hostname&:&portnumber& /&your_app_context_root&/servlet/com.ibm.ws.webcontainer.httpsession.IBMTrackerDebug
来查看具体 session 信息，如清单 1 所示：
清单 1. 服务器 session 信息示例
Session Tracking Internals J2EE NAME(AppName#WebModuleName):: tri-ear#tri-web.war cloneId : 15fm7sgs8 Number of sessions in memory: (for this webapp) : 9 Invalidation alarm poll interval (for this webapp) : 126 Max invalidation timeout (for this webapp) : 1800 Using Cookies : true Using URL Rewriting : false use SSLId : false URL Protocol Switch Rewriting : false Session Cookie Name : JSESSIONID Session Cookie Comment : SessionManagement Session Cookie Domain : Session Cookie Path : / Session Cookie MaxAge : -1 Session Cookie Secure : false Maximum in memory table size : 1000 current time : Thu Oct 28 15:26:29 GMT+08:00 2010 integrateWASSec :true Session locking : false Sessions Created:9 Active Count:0 Session Access Count:3707 Invalidated Sessions Count:0 Invalidated By SessionManager:0 SessionAffinity Breaks:0 Number of times invalidation alarm has run:38 Rejected Session creation requests(overflow off):0 Cache Discards:0 Attempts to access non-existent sessions:27 Number of binary reads from external store:27 Total time spent in reading from external store(ms):0 Total number of bytes read:-27 Number of binary writes to external store:939 Total time spent in writing to external store(ms):63 Total number of bytes wriiten out:-939 Session count 9 No of Replicated Sessions in the backup table(for this server) : 41 Total size of serializable objects in memory :42340 Total number objects in memory :9 Min size session object size:4687 Max size session object size :4826
在清单 1 里，我们可以看到目前在内存中针对名为 tri-web 的应用的 session 数目为 9，该服务器总共创建了 9 个 tri-web 应用的 session，同时备份表里面的 session 数目是 41。值得注意的是， 内存 (in-memory) 的 session 和备份表 (backup table) 里的 session 过一段时间后就会过时，这些过时的 session 会被服务器删除，一旦 session 被删除，以下两个数据统计值就被清零。
No of sessions in memory: (for this webapp)
No of Replicated Sessions in the backup table(for this server)
但是 created session 记录的是 session 创建的历史数据，只要服务器没有被重启，created session 里的数目只会随着 session 的创建而不断增加。
那么如何来诊断复制域成员的 session 复制服务是否正常工作？在下文中，我将分别介绍两种复制拓扑结构的实际用户场景，以及如何通过 DebugSessionCrossover 来诊断 session 的复制服务是否工作正常。
用户场景一：“点对点”复制拓扑结构
某用户创建了一个集群，该集群包含 3 个应用服务器，这 3 个应用服务器都是属于同一个复制域，并且该复制域的副本数选择“整个域”。然后用户把应用安装到这 3 个应用服务器上，并且把他们配置成“点对点”复制的拓扑结构。然后用户不断发送请求到这些应用服务器上，由于在 WebSphere Application Server 里默认的 session 超时时间为 30 分钟，为了避免超时以及 session 过期带来的干扰，我们简化场景，压力测试只跑 15 分钟，压力测试结束后等候几分钟以保证所有 session 处理完毕，最后再通过
http://&hostname&:&portnumber&/&your_app_context_root&/servlet/com.ibm.ws.webcontainer.httpsession.IBMTrackerDebug
来查看具体 session 信息。当然用户也可以通过控制台来更改 session 超时时间间隔，如图 8 所示，但是在实际应用中 session 超时时间不宜过长，否则 session 无法及时清除，占用大量内存空间，从而影响服务器的性能。
图 8. 更改 session 超时时间
通过使用 IBMTrackerDebug.Servlet， 我们可以检查所有复制域成员备份表中的 session 数目，所有复制域成员创建的 session 数目和复制域成员数目，应该满足如下公式：
所有复制域成员备份表中的 session 数目总和 = 所有复制域成员创建 session 的数目总和 *（复制域成员数 – 1），也就是说，所有服务器创建的 session，在其他所有复制域成员有都有一份备份。
例如在上面的用户场景中，我们得到如下的统计数据：
３个复制域成员备份表的 session 数目总和为：15+17+16 = 48, 如清单 2 所示 .
清单 2. 点对点复制域成员备份表的 session 数目
*********************************************************************************** .:9080/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug No of Replicated Sessions in the backup table(for this server) : 15 .:9081/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug No of Replicated Sessions in the backup table(for this server) : 17 .:9082/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug No of Replicated Sessions in the backup table(for this server) : 16 ***********************************************************************************
3 个复制域成员创建 session 的数目总和 *（复制域成员数 – 1）= （9+7+8）*（3-1）=48, 如清单 3 所示 .
清单 3. 点对点复制域成员创建的 session 数目
*********************************************************************************** .:9080/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug Sessions Created: 9 .:9081/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug Sessions Created: 7 .:9082/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug Sessions Created: 8 ***********************************************************************************
根据上面的数据，我们可以看到该集群所有复制域成员的 session 复制服务正常工作。
用户场景二： “客户机 / 服务器”复制拓扑结构
某用户创建了一个集群，该集群包含 3 个应用服务器，这 3 个应用服务器都是属于同一个复制域，并且该复制域的副本数选择“单个副本”。然后用户把应用安装到这 3 个应用服务器上，并且把他们配置成“客户机 / 服务器”复制的拓扑结构。同样用户不断发送请求到这些应用服务器上，一直到压力测试结束。然后通过
http://&hostname&:&portnumber&/&your_app_context_root&/servlet/com.ibm.ws.webcontainer.httpsession.IBMTrackerDebug
来查看具体 session 信息。如果“客户机 / 服务器”复制拓扑结构满足如下公式：
复制域成员备份表中的 session 数目总和 = 复制域成员创建 session 的数目总和
那么我们就认为该拓扑下的复制服务正常工作。否则用户就要重新检查自己的配置是否正确。
例如在上面的用户场景中，我们得到如下的统计数据：
３个复制域成员备份表的 session 数目总和为：20+21+17 = 58, 如清单 4 所示 .
清单 4. 客户机 / 服务器复制域成员备份表的 session 数目
*********************************************************************************** .:9080/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug No of Replicated Sessions in the backup table(for this server) : 20 .:9081/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug No of Replicated Sessions in the backup table(for this server) : 21 .:9082/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug No of Replicated Sessions in the backup table(for this server) : 17 ***********************************************************************************
3 个复制域成员创建 session 的数目总和 =18+20+20 = 58, 如清单 5 所示 .
清单 5. 客户机 / 服务器复制域成员创建的 session 数目
*********************************************************************************** .:9080/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug Sessions Created: 18 .:9081/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug Sessions Created: 20 .:9082/TriBookStore/servlet/com.ibm.ws.webcontainer.httpsession .IBMTrackerDebug Sessions Created: 8 ***********************************************************************************
根据上面的数据，我们可以看到“客户机 / 服务器”的复制拓扑工作正常。
值得注意的是，以上两个公式的使用都具有一定的局限性。它不适用于存在 session 过期的场景，因为 session 经常会过期，根据 session 复制原理，对于过期的 session，其备份也会被从其他复制域成员上删除，而这中间，复制域成员之间通信会有一定的延迟，所以造成某一时刻，这个公式不再适用。
本文主要介绍了在 WebSphere Application Server 集群环境下如何通过内存到内存的两种复制拓扑有效地管理 HTTP session。并对两种拓扑使用以及各自的优势和局限性作了进一步的阐述。最后，本文以示例的方式，向读者分享如何通过 DebugSessionCrossover 来查看复制域成员上的 session 统计信息。实际使用中，用户需要根据需要，选择合理的复制拓扑，从而达到其业务需求。
浏览: 25303 次
来自: 深圳