《WebSpherMQ教程》PPT课件.ppt

1,Web Sphere MQ教程,2,提要,Websphere MQ 介绍 安装和配置Websphere MQ Websphere MQ 集群 Websphere MQ 分布式队列管理 Websphere MQ 故障诊断,3,议程,MQ概念 中间件 MOM 异步通信 消息原理 MQ对象 演示 Reference (备用) 应用案例,4,MQ简史,1992 SSI(Server Side Includes,服务器端包含)，开发了消息产品ezBridge; IBM为网络通信定义了3个API标准： CPI-C, RPC, MQI 1992-3 IBM开发消息产品（代码 Victory） 1993 IBM从SSI那里购买了ezBridge的版权 之后MQSeries version1 产生（主要运行在大型机上） 1994/1995 IBM发布三个平台的MQ: AIX, OS/2, 和 AS/400. 到MQSeries 5.3 (WebSphere MQ5.3)已支持超过35个平台 Windows, Linux, 多个Unix, 2006年初 WebSphere MQ 6 发布,CPIC(Common Programming Interface Communication, IBM公共通信编程接口) 是一个与平台无关的API，它与一套公用的APPC（高级程序间通信）接口。 简单直接，在支持CPI-C的所有平台上都可移植。 CPI-C旨在为跨IBM平台执行应用程序提供一个公用环境。这些平台包括 IBM MVS（多重虚存系统）、VS（虚存系统）、OS400和基于OS/2的系统等。,5,RFC(远程过程调用): 架构在CPI-C接口之上，RFC的调用都将转换为CPI-C的调用完成.,6,7,什么是WebSphere MQ(MQ Series)?（1.1）,是一种中间件产品，它实现了一个消息队列框架. 中间件 将不同的计算环境连接起来的中间软件. Unix, MVS, OS/400, VMS, Windows NT/2k, etc. SNA, NetBios, TCP/IP Cobol, C, JAVA 是介于应用与操作系统之间的系统软件，是相关应用的基准平台。,8,MQ概念 中间件（1.1.2）,9,三种通信技术的比较（1.2）,CPI-C 同步的对话通信模式 RPC（远程过程调用） 同步的、对话方式的模型 MQI（Message Queue Interface，消息队列接口） 为程序提供了一种异步通信方式，一个程序以一个队列作为中转与另一个程序相互通信,10,MQ概念 Message Oriented Middleware（1.3）,简单地说，MOM就是这样的中间件，它允许一个应用向另一个应用发送消息，而无论该应用是否在线。,平台 A,消息队列 子系统A,应用A”放入“消息,平台 B,消息队列 子系统B,应用B” 获取“消息,消息队列,11,MQ概念 消息和队列,消息 程序之间的通信是通过发送消息数据而不是相互间直接调用. 队列 消息通过放入队列而存储下来, 减少了程序间逻辑性连接的需要. 消息传输系统 应用程序接口,12,MQ概念 异步 vs. 同步通信,消息队列框架的通信模式是异步的！ 同步: 应用发送请求后一直等待，直到请求被处理。 客户端请求的同时，服务必须在线。 异步: 应用发送请求，然后在将来检查请求是否被处理完成。 客户端请求时，服务无需在线。,13,14,同步的 good/bad,易编程 输出立即可知 更易恢复错误 (通常) 更好实时响应 (通常),服务必须启动、在线 请求方阻碍占用资源 通常要求面向连接的通信协议,Good,Bad,15,异步的 good/bad,请求无需指定服务器 服务无需在线 由于没有占用, 资源可以释放 可以使用非连接协议,响应时间不可预测 错误处理通常复杂 难以设计程序?,Good,Bad,16,消息的长处,消息的长处：,我们可以集中精力去做应用本身的设计.,再也不用管有关环境方面的细节了.,应用变得可以移植、扩展了.,17,图解消息工作原理,程序通过放置消息到队列来进行通信. 图中, A程序 将消息放入 Queue1, B程序读取Queue1的消息.,Note: A 和 B 不必位于同一台机器上!,18,消息工作原理 (2),通信可以是单向或者双向。图中, A 发送到 B上的Queue1, 然后B又 响应到 A 的Queue2,19,消息工作原理 (3) 之 消息队列特性,关于消息队列，有三个关键事实使得它不同于其他通信方式: 1) 要通信的应用程序可以运行在不同时间. 2) 对于应用间的结构没有限制. 3) 对于应用程序来说，底层的环境差异被屏蔽掉. 让我们一一看去.,20,消息队列特性 - 应用程序可以运行在不同时间,程序A,B不必同时在线,关键: 消息队列相对于使用它们的应用而言是独立存在的!,21,消息队列特性 对于应用间的结构没有限制,应用之间可能是一对多,或者是多对一,22,消息队列特性 环境差异被屏蔽掉,不用关心运行在什么OS之上. 不用关心程序由什么语言写的. 不用关心底层使用什么通信协议.,23,消息队列特性 - 环境差异被屏蔽掉,应用程序,编程API,通过消息通道 进行通信,队列管理器,队列管理器,消息队列,24,WebSphere MQ的原理（ 1.3 ）,25,MQ对象（2.1）,队列管理器（Queue managers） 队列（Queues） 名字列表（Namelists） 分发列表（Distribution lists） 进程定义（Process definitions） 通道（Channels） 存储类（Storage classes）,26,MQ对象: 队列管理器（Queue Manager）（2.1.4）,队列管理器 控制对队列的访问: 管理 (创建队列, 删除队列, 等) 使用 (放入, 读取 消息) 对于所有队列操作可统一进行事务控制. 通过MQI接口访问 如同主机名，队列管理器名字在网内必须唯一.,27,MQ对象: 队列（Queues）（2.1.3）,MQ定义了四种队列. 队列是用它的队列管理器和队列名称来完全确定的. 本地队列 实际队列，会为它分配存储空间. 包含传输队列。 远程队列 其他队列管理器上的队列的映射定义 (类似于指针、引用) 别名队列 某一本地或远程队列的别名. (用于编程的灵活性) 模型队列 队列模板，可用于创建本地队列 (“ create queue xxx “like” queue yyy).,28,MQ对象：队列的属性,最大消息长度 最大队列深度 允许/禁止 放入消息 或 取出消息 持久/非持久 用法：正常/传输,Demo： MQ资源管理器,29,MQ对象: 消息通道（2.1.4）,定义：为两个队列管理器（相同或不同平台）提供通信的通路. 一个消息通道只能在一个方向上传送消息. 如要双向通信，就得在队列管理器间建立两个消息通道. 一个通道可以为队列管理器上的任意多个队列服务,30,MQ对象: 消息通道（2）,通道类型: Sender 发起到Receiver的连接 Server 接受requester的请求, 变成Sender通道 Receiver 被动; 等待Sender的连接 Requester 启动时活动, 变成Receiver通道 Cluster-sender (用于队列管理器集群) Cluster-receiver (同上),31,MQ对象: 消息如何在通道传输,(1) 应用程序将消息放入传输队列,(2) Sender MCA取出消息然后发送到 partner MCA,(3) Receiver MCA 将消息放入目标队列,(4) 对于应用来说消息可用了,32,MQ对象: 有保障传输,若队列是持久的, 消息也是持久的, 则MCA最终一定会将消息传送到目标队列, 进而被目标应用获取! MCA是可恢复的（有状态的），而且是面向连接的协议. 消息不会从传输队列中删除，除非对方MCA确认消息到达了目标队列 消息通道代理（message channel agents，MCA）,33,MQ对象: 消息（2.1.2）,消息包含有: 消息头 (MQMD) 包含消息的属性（由QM和程序处理） 用户数据 程序到程序的数据 (“负载”) 对于 MQ来说是透明的,34,MQ对象: 消息属性,目标队列 应答队列名 可存在时间 (失效时间) 格式 相关标识 持久性 “报告” 选项,35,MQ的体系结构（2.2）,WebSphere MQ 和消息排队 WebSphere MQ 使应用程序通过使用消息排队来实现消息驱动处理，使用对应的消息排队软件产品实现在不同平台之间进行通信。从而使应用程序屏蔽了底层的通讯结构。 WebSphere MQ 产品提供了消息队列接口（或 MQI）的公共应用程序编程接口，如果应用程序使用了MQI，将非常容易将应用程序从一个平台移植至另一个平台。,36,2.3客户机和服务器 WebSphere MQ 支持其应用程序的客户机服务器配置。 WebSphere MQ客户端通过MQI通道与WebSphere MQ服务器进行通讯。,37,2.4触发机制 2.4.1触发的概念 2.4.2触发类型 2.4.3触发的工作原理,38,队列管理器群集（2.5）,群集的概念 群集的优点 群集的组件 创建群集 群集管理,39,在Websphere MQ集群中，成员队列管理器可以创建本地队列，并将其在集群中共享，集群中的其他成员队列管理器不需要任何额外的配置操作，就可以像访问本地队列一样向该队列放入（PUT）消息； 每个成员队列管理器都可以创建与之同名的共享队列，于是该共享队列在集群中就拥有了多个副本，所有的副本将作为一个虚拟的整体； 对访问者（调用MQPUT的应用）而言，它们就是一个队列，应用不需要关心如下细节： 物理上有多少队副本； 队列副本部署的物理列位置； 消息实际发送到哪个队列副本。 所有这些细节问题由集群负责处理，由此实现了集群的负载均衡功能。,为了减少应用程序对于它所运行环境的依赖性，WebSphere MQ的应用程序可以和一个它不知道名字的队列管理器相连，这个队列管理器就是一台机器上的缺省队列管理器。如果程序在调用MQCONN时，把队列管理器名参数设置为空，MQCONN将返回与缺省的队列管理器连接的句柄。,40,41,如果要从集群的外部发送消息到集群，并希望消息在集群的成员间合理的分配，那么集群中作为与外部环境接口点的队列管理器上就不能存在任何共享队列的副本，否则所有消息将积压在接口点队列管理器上，使集群的负载均衡功能英雄无用武之地。 通常的解决方案是为集群配置至少一个特殊的队列管理器，通常称为网关（Gateway）队列管理器，该队列管理器上没有任何共享队列的副本，只需配置与集群外部的通讯设置（通道、监听器等）和相关的队列管理器别名（Queue-manager alias）。建立队列管理器别名的方法是建立一个RNAME属性为空的远程队列。,42,WebSphere MQ 互连通信,基本概念 实现应用程序通信 通道的维护 配置侦听程序,43,WebSphere MQ 恢复和重新启动,WebSphere MQ的数据日志 使用数据日志进行恢复 保护 WebSphere MQ 日志文件 备份和恢复 WebSphere MQ 恢复方案 使用 dmpmqlog 命令转储日志,44,WebSphere MQ 问题诊断,错误日志 死信队列 配置文件和问题确定 跟踪 首次故障支持技术（FFST）,45,WebSphere MQ 问题诊断,WebSphere MQ 使用许多错误日志来捕捉WebSphere MQ自身的操作、任何队列管理器的启动和正在使用的通道的错误信息。 错误日志的位置取决于队列管理器名，以及错误是否与客户机相关。,8.1 错误日志分析,在 WebSphere MQ Windows 版中，假设 WebSphere MQ 已经安装在缺省位置中： 如果队列管理器名称是已知的，则错误日志位于： c:Program FilesIBMWebSphere MQqmgrsqmnameerrors 如果队列管理器不是已知的，则错误日志位于： c:Program FilesIBMWebSphere MQqmgrsSYSTEMerrors 若错误与系统有关，则错误日志位于： c:mqmerrors 如果错误发生在客户机应用程序，则错误日志位于客户机的根目录中： c:Program FilesIBMWebSphere MQ Clienterrors,46,日志文件,在MQ产品安装时，在qmgrs路径下会建立SYSTEM的子目录，在errors子目录下会产生三个日志文件： AMQERR01.LOG AMQERR02.LOG AMQERR03.LOG,47,当你建立了队列管理器以后，该队列管理器所需的日志文件随之产生。在mqmqmgrQMgrNameerrors子目录下会产生三个日志文件： AMQERR01.LOG AMQERR02.LOG AMQERR03.LOG 每个文件的大小为：256KB。,48,当错误信息产生后，被放在AMQERR01.LOG中。当AMQERR01.LOG大于256KB时，AMQERR01.LOG中的信息被拷贝到AMQERR02.LOG中，新的错误信息又放在AMQERR01.LOG文件中，依此类推。,49,最新的错误信息总是存储在AMQERR01.LOG中，历史信息存储在AMQERR02.LOG 和 AMQERR03.LOG中。应该按照该顺序察看错误信息，并从该文件中获取信息，根据它的提示采取相应的措施： 如果TCP/IP出错，需要检查一下网络状态是否正常； 如果发现无法连接对方的队列管理器，需要检查一下对方的MQ是否处于运行状态以及对方的通道侦听程序是否启动； 如果错误日志显示“通道未在远程定义”，可以检查定义的通道的大小写是否正确等。,50,8.2 常见故障分析,在开始详细分析问题的原因之前，应该首要考虑一下可能导致问题的一些较明显的因素，或导致问题发生的最大可能性因素，这样便于把分析问题的范围限制到最小。 有关的MQ的异常情况的发生，通常主要与三方面的因素有关，即： MQSeries本身 网络 客户的应用,51,8.2.1 初步分析,基本问题罗列： 此之前MQ是否运行正常？ 从最近一次成功运行以来，是否在某些地方作过改动？ 在此之前，应用是否运行成功？,52,如果系统曾经运行正常，那麽在出现问题之前，对哪些部分做了改动？ 如：有的用户可能由于网络重新规划而更改了某个主机的IP地址，则可能导致通道无法连通； 有的用户新设置了防火墙，则需要进行相应的配置，才能使MQ的通道运行正常。 如果没有对系统配置做过更改，可以分析是否运行环境发生了变化？ 如：是否由于业务量的加大导致应用程序队列满了，需要加大队列的最大深度；是否由于连接数量的增加，导致无法建立新的连接，这时需要察看在队列管理器配置文件中，与通道相关的MaxChannels和MaxActiveChannels的配置是否足够大。,53,有无错误信息？ 可以察看错误日志，得到错误信息。 是否与MQI应用有关，利用返回码能否解释原因？ 对于每一个函数调用，MQ都会返回一个Completion Code和Reason Code，通过MQI返回码Reason Code，可以在API一层，确定错误原因，Reason Code代表的含义可以参考编程手册，或者从cmqc.h头文件中获得。如：RC2035，代表没有操作权限；RC2085，表示没有该对象；RC2080，表示应用程序给出的buffer小于消息的实际大小等。 问题能再现吗？ 从最近一次成功运行以来，是否在某些地方作过改动？ 在此之前，应用是否运行成功？ 网络是否连接正常？ 问题是否总在每天的某一固定时刻发生？,54,8.2.2 深入分析, 与队列相关的问题 1) 队列状态是否正常？ 用DISPLAY QUEUE命令查看队列的各项状态 用得到的队列信息进一步查看： a) 如果CURDEPTH达到MAXDEPTH，表明队列深度已满，新消息已不能再进入队列，要及时处理队列中积存的消息；或者增大队列的MAXDEPTH属性。 b) 如果CURDEPTH还没有达到MAXDEPTH，再考虑以下两种情况： 如果队列被设置为可触发类型的，要检查触发条件有没有满足？相关触发进程的定义是否正确？ 如果队列不是触发类型的，要检查队列是否为可共享的，是否允许PUT或GET的操作等。,55,2) 消息是否成功地放入队列? 如果消息没有成功地放入队列，可以检查： 队列是否被正确定义?例如，队列的MaxMsgLength属性是否足够大以容纳所需大小的消息? 队列是否被允许放入? 队列是否已满?这可能意味着应用程序无法将要求的消息放入队列。 有没有另一个应用程序取得了独占队列的权力?,56,3) 是否可以从队列取出任何消息? 如果无法从队列中取出任何消息，检查： 其他应用程序能否从队列中取出消息? 有没有另一个应用程序取得了独占队列的权力?,57,如果正在开发应用程序，检查： 是否需要使用一个同步点? 如果使用同步点控制来放入或检出消息，它们直到工作单元被提交前不能用于其它任务。 是否等待了足够长的时间? 作为MQGET调用的一个选项，可以设置等待间隔。应该确保等待响应足够长的时间。 是否在等待一条由消息或相关标识符（MsgId或CorrelId）标识的特定消息?,58,检查在等待的消息的MsgId或CorrelId是否正确。成功的MQGET调用会把这些值设置为检索到的消息的值，所以可能要重设这些值以便成功地取出另一条消息。 对消息是否进行了分段处理，是否在利用MQGET读取消息时，采用了正确的选项(MQGMO)，从而获取消息的整体。 还要检查一下是否能够从队列中取出另一条消息。 期望的消息有没有被定义为持久的? 如果没有，并且MQ重新启动后，消息将已丢失。,59,4）问题是否与远程队列有关？ 如果问题是否与远程队列有关，则要考虑以下几个方面： 远程队列的定义是否正确； 检查通道是否启动，如果通道是可被触发的，要检查触发监视器是否运行正常； 检查往远程队列里发送消息的应用程序是否运行正常； 从错误日志中查找信息；,60, 与通道相关的问题 通道状态异常时应采取的措施： 1) 查看网络连接是否畅通 MQ的通讯是建立在系统网络运行正常的基础之上的，当通道不通时，要首先检查网络连接是否正常。您可以使用操作系统ping命令，也可以采用ftp方式，在两个主机之间尝试进行数据传输，以判断网络是否正常。 2) 查看通道定义是否正确 通道所使用的传输队列定义是否正确，通道两端的定义是否匹配，如两条通道最大传输的消息长度，Message sequence number wrap是否一致。若不一致，要重新定义通道，可使用MQSC命令DEFINE CHANNEL命令。,61,3)查看通道的状态 用以下命令来判断通道状态： dis chstatus(ChannelName)或dis chs(ChannelName) 其中，ChannelName代表通道的名称，该命令支持通配符，可用dis chs(*)来查看所有通道的状态， 当通道无法正常启动时，必须重新启动通道，可使用MQ的控制命令runmqchl命令，或MQSC命令START CHANNEL来启动通道。 注意：如果通道的接收方状态处于STOPPED状态，必须用start chl(ReceiverChl)来重置它的状态，注意，这并不意味着启动了通道，欲启动通道，必须从发送端来启动。,62,如果通道处于可疑(in-doubt)状态，则通道启动阶段的互相同步工作无法完成，也会导致通道无法启动。解决方案是：用Resolve Channel命令来确定通道状态；Resolve Channel命令带有两个参数：COMMIT和BACKOUT，用COMMIT参数将传输队列中的消息删除，用BACKOUT参数将传输队列中的消息重新恢复。,63,4) 查看操作系统、MQ的TCP/IP参数是否设置成功以及runmqchi进程是否处于运行状态 如果通道在网络出现异常或对方队列管理器重启后，MQ通讯不能正常恢复，则要检查操作系统的keepidle的TCP/IP相关参数是否设置成功并且生效，同时要检查队列管理器的属性TCP: KeepAlive是否设置为Yes，另外，runmqchi进程是否处于运行状态。 注意：上述三者共同作用，才能保证MQ通道的正常恢复，缺一不可。,64,5）查看通道的当前消息序列号 用dis chstatus(ChannelName)或dis chs(ChannelName)查看通道的当前一些属性值，在通道的属性值中，current sequence number代表通道当前的消息序列号值，若消息序列号不一致，则可用MQSC命令RESET CHANNEL命令来将消息序列号重新置1。 注意：一般情况下，只有当某一方MQ系统重新安装，队列管理器重建，或人为操作时，才会使通道的消息序列号变为1。,65,6) 查看错误日志 关于MQ提供的错误日志之前已经作过较为详细的介绍，错误日志是出现异常情况时，系统管理员查找原因时要最先考虑也最为简洁奏效的办法。通道错误日志中的错误信息，往往能很快解决问题。 通常从以上几方面考虑，通道问题都能迎刃而解。,66, 死信队列 如果由于某种原因，消息不能被正常发送，它会被送到死信队列中。你可以用MQSC目录DISPLAY QUEUE来查看死信队列的深度，若队列中有消息，可利用应用程序浏览消息的内容，来确定消息被放入死信队列的原因，从而确定如何处理死信中的消息。消息有可能出现在本地的队列中，也有可能出现在目的地的死信队列中。若发生前一种情况，说明本地某有正确的路由途径，可以使消息继续下传；若发生后一种情况，说明目的地一端所指定的目的队列不存在。,67, 配置文件 对于每一个队列管理器而言，都有一个名为qm.ini的配置文件，如果该配置文件被误删除，会导致“queue manager unavailable”类型的错误。在Windows NT/2000平台上，该配置文件以注册表方式存在，可以使用MQ提供的图形界面进行修改。注意：对qm.ini和队列管理器属性的修改，必须在队列管理器重新启动之后才能生效。,68, 数据日志 前面曾经提到MQ的数据日志，一般情况下，中国用户大多采用循环日志，我们建议您在估算消息容量之后，确定适当的日志大小和个数。如果，在运行过程中，出现了日志写满的情况，MQ也无法正常运行，您可以采取修改qm.ini配置文件的方法，加大日志大小和个数。,69,8.2.3 查看系统及应用的运行情况,若从上述两个方面都没有解决问题，最后您就要从系统和应用的角度去进一步分析问题了，比如，您可查看您的系统运行速度是否正常，系统资源是否耗尽等，从而确认是否系统问题影响了MQ的正常运行。,70,8.3 Trace,错误跟踪也是一种跟踪故障的手段，在MQ for Windows NT/2000环境中，我们可以用“strmqtrc”命令来追踪问题的发生原因。 Trace文件除特殊指定，一般放在mqmworkerrors目录下，文件的命名规律是：AMQppppp.TRC (注：ppppp是产生trace的进程标识符(PID)。 注意：启动trace跟踪，会影响系统的性能，所以在生产环境中要慎重使用。Trace文件的内容，用户是无法分析和读懂的，要由IBM实验室进行分析。,71,8.4 FFST(First Failure support technology),在WindowsNT环境中，FFST消息文件位于c:mqmerrors目录下。这些错误一般较为严重，一般表现为系统错误或MQ内部错误。 FFST文件的命名规则为：AMQnnnnn.mm.FDC nnnnn-报告错误的进程标识符(PID) mm-序列号，一般为0,72,在FDC文件中，对我们有帮助的是它的开始部分，我们可以参考它的ErrorCode, Probe Type, Probe Description部分的内容来分析原因。它的主要部分也是需要由IBM试验室来分析的，IBM借助MQM Function Stack和MQM Trace History来分析故障原因。,73,74,演示,演示一 将消息发送至本地队列 创建队列管理器 创建本地队列 将测试消息放入本地队列 验证是否已发送测试消息 演示二 将消息发送至远程队列 创建队列管理器 在发送队列管理器上创建队列 创建消息通道（Sender,Receiver） 将测试消息放入队列 验证是否已发送测试消息,75,参考 (Reference),IBM WebSphere MQ home - /software/int