Win7-IBM Websphere MQ7 虚拟机下载

本博主已经安装与配置好的windows7 环境下的mq7虚拟机环境,链接:https://pan.baidu.com/s/1YJpcQbkO0fo27i_ZHfe6nQ
提取码:yrxc
下载后,解压后,可以用vmware workstaion 打开,直接使用。

MQ帮您搭建企业服务总线(ESB)的基础传输层。IBM WebSphere MQ为SOA提供可靠的消息传递。它为经过验证的消息传递主干, 全方位、 多用途的数据传输, 并帮助您搭建企业服务总线的传输基础设施。
消息队列(MQ)是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据(消息)来通信,而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信,而不是通过直接调用彼此来通信,直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。
IBM WebSphere MQ 支持两种不同的应用程序编程接口:Java 消息服务(JMS)和消息队列接口(MQI)。在 IBM WebSphere MQ 服务器上,JMS 绑定方式被映射到 MQI。应用程序直接与其本地队列管理器通过使用 MQI 进行对话,MQI 是一组要求队列管理器提供服务的调用。MQI 的引人之处是它只提供 13 次调用。这意味着对于应用程序编程员它是一种非常易于使用的接口,因为大部分艰苦工作都将透明完成的。
IBM WebSphere MQ 产品支持应用程序通过不同组件如处理器、子系统、操作系统以及通信协议的网络彼此进行通信。

功能编辑
· 跨任何商业IT系统连接应用程序和Web服务, 提供完整的JMS(Java消息服务)支持 [1] , 包括发布-订阅。
· 对Web服务的整合化支持。
· 基于Eclipse的新工具—MQ Explorer, 适用于Windows和Intel(x86), 支持整个消息传递主干的远程和安全配置。
· WebSphere MQ V6.0.2增强了JMS和安全性, 构建在WebSphere MQ V6.0中引入的新配置工具之上, 该工具以新Eclipse插件的形式提供, 可增强您的MQ Explorer控制台。
· 与WebSphere Application Server的消息传递服务无缝互操作。
· 支持行业标准安全套接字层(Secure Sockets Layer, SSL)安全性, 并提供扩展安全版本来获得高级安全特性。
· 支持推进现有FTP基础设施, 确保通过WebSphere MQ进行可靠、 安全的文件传输。
· 支持的操作系统: AIX、 HP Unix、 i5/OS、 Linux、 Sun Solaris、 Windows、 z/OS。
操作程序编辑
第一步是让应用程序与队列管理器连接。它通过 MQConnect 来进行此连接。下一步调用 MQOpen 为输出打开一个队列。然后应用程序调用MQPut 将其数据放到队列上。要接收数据,应用程序调用 MQOpen 打开输入队列。应用程序调用MQGet 从队列上接收数据。

在开始之前,让我们先来确定使用 WebSphere MQ 解决的业务问题的种类,并了解 WebSphere MQ 如何能够帮助您满足业务要求。

问题:自动化孤岛

在大多数业务中,业务的信息技术 (IT) 基础结构中存在许多不同的技术。系统由这些来自许多供应商的不同的技术组成,并且具有不同的硬件平台、编程语言、操作系统和通信链路。通常,连接不同的系统非常复杂并且可能代价高昂,所以许多系统之间都相互隔离。

目前,越来越多的业务还需要以电子的方式与其客户和供应商进行通信,而这些客户和供应商可能比该业务本身使用了更多不同的技术。因此,需要某种简便的、廉价的和可靠的机制用来连接这些异类的系统(“自动化孤岛”),以便在内部和外部对业务的 IT 基础结构进行集成。

解决方案:WebSphere MQ

通过提供一种程序到程序的通信方式,WebSphere MQ 非常适合于上面所描述的环境。图 1 显示了这种通信方式的基本机制。

程序 A 准备好一条消息,并将其放入队列。然后,程序 B 从该队列中获取消息,并对其进行处理。这两个程序都使用一种应用程序编程接口 (API) 与该队列进行交互。WebSphere MQ API 称为消息队列接口 (MQI)。任何一个程序都无需了解对方的存在,并且这两个程序无需同时执行。如果程序 A 在程序 B 尚未执行的时候将一条消息放入队列,那么该队列将存储这条消息,直到程序 B 开始执行并准备处理这条消息。类似地,当程序 B 从队列中检索消息时,程序 A 可能已经不再处于执行状态。

应用程序设计

使用 WebSphere MQ 提供的基本通信机制,可以进行同步和异步的应用程序设计。

在同步的应用程序设计中,如图 2 所示,假定同时执行这两个应用程序。程序 A 向队列 1 发送一条消息并等待应答。程序 B 检索得到该消息,并对它进行处理,然后将应答消息发送到队列 2 中,以便程序 A 进行检索。在使用 WebSphere MQ 设计应用程序时,通常每个程序使用不同的队列向其他程序发送消息。虽然这不是必需的,但这样可以提供更简单的应用程序设计和编程逻辑。另外请记住,这里假定两个程序同时执行。如果当程序 A 发送消息时,程序 B 没有执行,那么程序 A 将阻塞,直到程序 B 启动并对消息进行处理。这是同步应用程序通信中的设计问题。

在异步应用程序设计中,如图 3 所示,程序 A 再次将消息放到队列 1,以便程序 B 对其进行处理,但现在,程序 C 与程序 A 进行异步地操作,它检索消息并对其进行处理。通常,程序 A 和程序 C 是相同应用程序中的不同部分。

对于 WebSphere MQ 来说,异步设计是一种非常合适的模型。程序 A 将消息放到队列中,并继续执行,即使程序 B 并不对这些消息进行处理,也是如此。在这种情况下,队列将存储这些消息,直到程序 B 重新启动。这种模型有一种变种,即程序 A 将一条或多条消息放到队列中,并继续进行其他的处理,然后返回来检索和处理应答消息。

程序之间的这种通信方式称为消息传递。它与其他通信方式(如对话式的通信或调用和返回通信)的不同之处在于,进行通信的程序之间具有时间独立性。程序接收消息作为输入,并输出其结果作为消息,而不需要同时运行发送或接收程序。

本博主已经安装与配置好的windows7 环境下的mq7虚拟机,链接:https://pan.baidu.com/s/1YJpcQbkO0fo27i_ZHfe6nQ
提取码:yrxc
下载后,解压后,可以用vmware workstaion 打开,直接使用。

队列管理器和 MQI

WebSphere MQ 中的队列由队列管理器 所拥有并进行管理。队列管理器还为应用程序提供了 MQI API,允许它们访问队列以及其中包含的消息。MQI 在 WebSphere MQ 支持的所有平台中保持一致,并对应用程序隐藏了队列管理器的实现细节。

MQI 中有 8 种主要的调用:

MQCONN——连接到队列管理器

MQCONNX——使用连接选项连接到队列管理器

MQDISC——断开与队列管理器的连接

MQOPEN——打开队列以便进行访问

MQCLOSE——关闭访问的队列

MQPUT——将一条消息放入队列

MQGET——从队列中获取一条消息

MQPUT1——打开队列,放入一条消息,然后关闭该队列

MQI 中有 5 种次要的调用:

MQBEGIN——开始一个工作单元

MQCMIT——提交一个工作单元

MQBACK——回滚一个工作单元

MQINQ——查询 WebSphere MQ 对象(队列是一种 WebSphere MQ 对象,队列管理器是另一种对象)的属性

MQSET——设置 WebSphere MQ 对象的属性

消息

WebSphere MQ 中的消息包含两个部分:WebSphere MQ 使用的 Header 和应用程序数据。图 4 显示了一条 WebSphere MQ 消息。

应用程序数据可以包含任何字节序列。它是使用 WebSphere MQ 与其他应用程序进行通信的应用程序所私有的,并且对 WebSphere MQ 没有什么意义。对于应用程序数据的内容没有任何限制,但不同的平台所允许的消息的最大长度有所不同。在大多数系统中,最大长度为 100MB,但有些系统的最大长度为 4MB。

消息中可能包含各种各样的 Header,但所有的消息都包含一个称为消息描述符 (MQMD) 的 Header。其中包含了关于该消息的控制信息,队列管理器和接收应用程序将使用到这些控制信息。稍后将提供关于 MQMD 和其他 Header 的更详细的信息。

本地和远程队列

队列管理器可以位于相同或不同的计算机上,它们可以彼此通信,并在不同队列管理器的队列之间传递消息。队列管理器为消息提供了可靠的传递。例如,当应用程序将消息放入到队列中时,队列管理器将确保消息的存储是安全的、可恢复的,并向接收应用程序传递一次且仅传递一次,即使必须将消息传递到另一个队列管理器所拥有的队列,也是如此。

当应用程序打开队列时,应用程序所连接的队列管理器将确定该队列是队列管理器所拥有的本地 队列,还是由另一个队列管理器所拥有的远程 队列。对于本地队列,直接将消息放入到该队列。如果队列是远程的,那么队列管理器将消息放到一个称为传输 队列的特殊队列。

然后,消息通道代理 (MCA) 从传输队列中获取消息,并将其通过网络发送到接收端的 MCA。接收 MCA 将该消息放到目标 队列。在将消息放到目标队列中之后,便将其从传输队列中删除。消息流在队列管理器之间可以是双向的,如图 5 中所示。

如果接收 MCA 不能将该消息放到目标队列中,那么将根据消息描述符中的选项对其进行处理。可能将其放到死信 队列,也可能将其返回给发送者,甚至将其丢弃。

通过这种在队列管理器之间传递消息的能力,WebSphere MQ 提供了两种重要的优点:

应用程序开发人员不需要了解网络的详细信息。

MCA 可以使用各种网络和通信协议与其他的 MCA 相互通信,并且甚至可以在一段时间之后更改所使用的协议。但是,应用程序开发人员仅需要了解与队列管理器通信所需的 MQI 调用。

仅需要建立更少的通信链路。

许多应用程序使用一个队列管理器,它们可以与使用另一个队列管理器的应用程序通信,但是在一对 MCA 之间只需要一条通信链路。

设计可能性

 

本博主已经安装与配置好的windows7 环境下的mq7虚拟机,链接:https://pan.baidu.com/s/1YJpcQbkO0fo27i_ZHfe6nQ
提取码:yrxc
下载后,解压后,可以用vmware workstaion 打开,直接使用。

现在您已经比较清楚地了解了 WebSphere MQ 的工作方式,即使仅仅是在概略的层次上,下面让我们来看看在使用 WebSphere MQ 设计系统时,应用程序设计的可能性。

并行处理

要完成总体的业务事务,应用程序可能需要执行多项任务。例如,旅行社可能需要预定航班、预订酒店房间和预订出租车。使用 WebSphere MQ,可以将请求消息放到为航班预定系统、酒店预订系统和轿车出租应用程序提供服务的 3 个队列中。每个应用程序都可以与其他两个应用程序并行地执行自己的任务,然后将应答消息放到旅行社应用程序提供的队列中。在收到这 3 个应答之后,旅行社应用程序可以生成综合的旅行路线。这种并行处理的方式可以极大地提高整体性能。

客户端/服务器处理

另一种应用程序设计方案是客户端/服务器处理。在这种情况下,一台服务器仅使用一个队列接收来自多个客户端应用程序的消息。每个请求消息的消息描述符可以指定一个应答队列。在服务器完成对消息的处理之后,它将应答消息发送到消息描述符中指定的应答队列,这样可以使得每个客户端应用程序相对于其他客户端应用程序独立地接收到其应答消息。

消息描述符中还有一个包含消息标识符的字段。应答消息的消息描述符可以包含对应的请求消息的标识符。这样做使得客户端应用程序可以在应答消息和以前发送的请求消息之间进行关联。

要使用客户端/服务器处理来提高应用程序的性能和可靠性,可以使用多个服务器应用程序实例为同一个请求队列服务。

触发

WebSphere MQ 可以在消息放入到队列中以及某些条件满足时,启动一个应用程序。这称为触发。下面是触发的工作方式:

程序将消息放入到支持触发的队列中。

如果触发的条件满足,则发生触发事件。

队列管理器检查应用程序队列所引用的进程对象。该进程对象指定了需要启动的应用程序。

队列管理器创建包含关于进程对象和队列的信息的触发消息。

将该触发消息放到启动队列。

由一个称为触发监视器 的程序负责检索消息,并启动合适的应用程序,将触发消息的信息传递给这个应用程序。

当第一次将消息放到队列中时、当队列中包含的消息达到某个数目时、或者每次将消息放到队列中时,都可能发生触发事件,尽管最后这种情况通常不推荐使用。

数据完整性

有些应用程序使用会话式的程序到程序的通信方式,以使用两段式提交协议来支持分布式工作单元的实现,如图 6 中所示。

这种功能仅在下面的情况下需要使用,业务要求在任何时刻都必须非常精确地维护两个分布式数据库之间的一致性。在实际中,这种类型的需求很少出现。当这种需求的确存在时,单个分布工作单元可能使用许多资源,并且变得非常复杂,尤其是当涉及到许多处理时。

WebSphere MQ 提供了一种更简单的解决方案,使得多个工作单元可以异步执行,如图 7 中所示。

第一个应用程序写入数据库,将包含对其他系统中的第二个数据库进行更新所需数据的消息放到队列中,然后提交对这两种资源的更改。因为该队列是远程的,所以消息仅进入第一个工作单元的传输队列。

第二个工作单元包含发送 MCA 从传输队列中获取该消息,并将其发送给接收 MCA,而后者负责将该消息放到目标队列。

在第三个工作单元中,第二个应用程序从目标队列中获取该消息,并使用该消息中包含的数据对数据库进行更新。

工作单元 1 和 3 的事务完整性,加上工作单元 2 中由 WebSphere MQ 提供的消息的一次且仅一次的可靠传递,从而确保了整个业务事务的完整性。

安全性

WebSphere MQ 中的安全特性包括:

队列管理器可检查某个用户是否经过授权可以提交管理队列管理器的命令。

队列管理器可检查某个用户或应用程序是否经过授权可以在指定的操作中访问 WebSphere MQ 资源,如队列。

在允许 MCA 之间进行消息通信之前,MCA 可以对合作伙伴 MCA 进行身份验证。

可以在 MCA 发送消息之前对其进行加密,然后在接收到该消息之后再对其进行解密。

消息描述符可以包含用户 ID 和关于消息发出者的其他信息。这种信息称为消息上下文,它可以用来对消息进行身份验证,并检查该消息的发送者是否经过授权可以访问接收系统中的 WebSphere MQ 资源。

WebSphere MQ 客户端

WebSphere MQ 客户端可以安装在没有运行队列管理器的系统中。客户端可以将在同一系统中运行的应用程序作为 WebSphere MQ 客户端,以连接到运行于另一个系统中的队列管理器,并向该队列管理器发出 MQI 调用。这种应用程序称为 WebSphere MQ 客户端应用程序,而这种队列管理器称为服务器队列管理器。图 8 显示了这种配置。

WebSphere MQ 客户端应用程序和服务器队列管理器使用 MQI 通道 实现彼此之间的通信。当客户端应用程序发出 MQCONN 或 MQCONNX 调用时启动 MQI 通道,当客户端应用程序发出 MQDISC 调用时结束该通道。

要使 WebSphere MQ 客户端进行有效地处理,需要快速的和可靠的同步通信连接。

本博主已经安装与配置好的windows7 环境下的mq7虚拟机,链接:https://pan.baidu.com/s/1YJpcQbkO0fo27i_ZHfe6nQ
提取码:yrxc
下载后,解压后,可以用vmware workstaion 打开,直接使用。

WAS GC日志native_stderr.log分析

 

我们可以通过添加JVM启动参数 -verbose:gc 或者在管理控制台上勾选详细垃圾回收选项来打印更详细的GC日志,缺省日志记录文件是native_stderr.log文件。

不同的GC策略,日志内容会有所不同,以下是optthruput策略时,记录的详细GC日志:
<af type=”tenured” id=”24″ timestamp=”Dec 31 14:51:48 2015″ intervalms=”494944.872″>

af(allocation fail):触发垃圾回收的事件,af为分配失败。如果是sys,则表示应用程序有显示调用System.gc()方法,不建议使用显示gc()方法,可以通过 -Xdisableexplicitgc参数屏蔽显式GC

type=”tenured”:GC类型,tenured/长存区的收集,另一种情况nursery/婴儿区收集

id=”24″:tenured区GC的次数,这是第24次tenured区的垃圾回收

timestamp=”Dec 31 14:51:48 2015″:GC发生的时间戳

intervalms=”494944.872″:距离上一次GC的时间

<minimum requested_bytes=”16944″ />

申请的堆大小为16944byte,垃圾收集并分配后,freebytes可能下降超过这个大小。原因是空闲列表可能会被丢弃或线程本地堆(TLH)刷新

<time exclusiveaccessms=”0.059″ meanexclusiveaccessms=”0.059″ threads=”0″ lastthreadtid=”0x0000000017093E00″ />

exclusiveaccessms=”0.059″:准备GC前花费的时间0.059ms

<refs soft=”2363″ weak=”12244″ phantom=”774″ dynamicSoftReferenceThreshold=”9″ maxSoftReferenceThreshold=”32″ />

refs:提供关于java对象引用的信息

soft=”2363″:2363个SoftReference/软引用对象。最先处理软引用对象,如果内存空间足够,就不会回收软引用对象

weak=”12244″:12244个WeakReference/弱引用对象。软引用对象处理完后,处理弱引用对象

phantom=”774″:774个PhantomReference/虚引用对象。弱引用对象处理完后,处理虚引用对象

dynamicSoftReferenceThreshold=”9″:软引用对象在被回收前可以生存的GC周期,此值会动态调整,如果堆空间使用率很高,可能会降低此阈值

maxSoftReferenceThreshold=”32″:软引用对象在被回收前可以生存的最大GC周期,32次

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ GC前堆空间使用情况↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

<tenured freebytes=”10241336″ totalbytes=”64998400″ percent=”15″ >

freebytes=”10241336″:空闲空间10241336byte

totalbytes=”64998400″:总空间大小为64998400byte

percent=”15″:空闲空间约占总空间大小的15%

<soa freebytes=”9781560″ totalbytes=”64538624″ percent=”15″ />

soa:小对象分配区域;在分配对象时,首先尝试在小对象区域中进行分配。如果找不到足够大小的可用项来满足分配,并且请求的大小等于或大于64KB,那么将再次在loa中尝试分配。如果请求大小小于64KB或者loa中没有足够的连续空间,那么将触发分配故障。如果小对象区域中的可用自由空间量远远大于分配请求大小,但是还无法满足请求,则表明堆中都是碎片。

freebytes=”9781560″:空闲空间9781560byte

totalbytes=”64538624″:总空间64538624byte

percent=”15″:空闲空间约占总空间大小的15%

<loa freebytes=”459776″ totalbytes=”459776″ percent=”100″ />

loa:大对象分配区域;大对象区域是堆中保留给大对象分配的一小片区域。垃圾收集器会根据loa空间的使用情况来进行扩展或收缩

freebytes=”9781560″:空闲空间9781560byte

totalbytes=”64538624″:总空间64538624byte

percent=”15″:空闲空间约占总空间大小的100%,即未使用

</tenured>

<pending-finalizers finalizable=”592″ reference=”5″ classloader=”0″ />

pending-finalizers:表示可终结队列的当前状态

<gc type=”global” id=”26″ totalid=”26″ intervalms=”494945.222″>

type=”global”:global/全局收集,另一种情况为scavenger/清扫

id=”26″:这是第26次发生全局GC

totalid=”26″:GC总共发生了26次

intervalms=”494945.222″:此次GC花费了494945.222ms

<finalization objectsqueued=”592″ />

<timesms mark=”95.729″ sweep=”1.073″ compact=”0.000″ total=”96.912″ />

mark=”95.729″:标记花费的时间95.729ms

sweep=”1.073″:清扫花费的时间1.073ms

compact=”0.000″:压缩花费的时间 0.000ms,未发生压缩

total=”96.912″:此次GC共花费了96.912ms

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ GC后堆空间使用情况↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

<tenured freebytes=”22360600″ totalbytes=”64998400″ percent=”34″ >

freebytes=”22360600″:空闲空间22360600byte

totalbytes=”64998400″:总空间64998400byte

percent=”34″:空闲空间约占总空间大小的34%

<soa freebytes=”21966360″ totalbytes=”64604160″ percent=”34″ />

soa:小对象分配区域;

freebytes=”21966360″:空闲空间21966360byte

totalbytes=”64604160″:总空间64604160byte

percent=”34″:空闲空间约占总空间大小的34%

<loa freebytes=”394240″ totalbytes=”394240″ percent=”100″ />

soa:大对象分配区域;

freebytes=”394240″:空闲空间394240byte

totalbytes=”394240″:总空间394240byte

percent=”100″:空闲空间100%

</tenured>

</gc>

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓满足分配后堆空间使用情况↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

<tenured freebytes=”22343656″ totalbytes=”64998400″ percent=”34″ >

<soa freebytes=”21949416″ totalbytes=”64604160″ percent=”33″ />

<loa freebytes=”394240″ totalbytes=”394240″ percent=”100″ />

</tenured>

<refs soft=”2354″ weak=”12073″ phantom=”774″ dynamicSoftReferenceThreshold=”11″ maxSoftReferenceThreshold=”32″ />

<pending-finalizers finalizable=”592″ reference=”5″ classloader=”0″ />

<time totalms=”97.038″ />

</gc>