消息队列管理（精选6篇）
消息队列管理 篇1
0 引言
机会网络[1]的节点利用其移动性, 在没有完整链路的网络中使用“存储-携带-转发”的路由方式传递消息。现存的基本网络管理策略有[2,3]:DL (Drop Last Received) :丢弃最新接收的副本;DLR (Drop Least Recently Received) :丢弃在缓存中驻留最久的消息副本;DOA (Drop the Oldest) :丢弃已生存时间最长的消息。KRIFA等人[4]根据副本的历史信息估计其在网络中的副本数, 并推导出能满足最小延迟以及最大传输率所需的删除条件。文献[5]提出了一种基于节点集群的缓存统一维护管理策略, 利用P2P网络[6]的相关技术, 将相邻的节点构成一个簇, 并将能量较高且较稳定的一个节点作为簇头, 通过组网内实时在簇头节点上建立更新树并发送更新的消息。请求节点与簇头的路由距离比它到源节点的路由距离相对较短, 因此这样的策略使节点网络连接更可靠、响应延迟更短和能量消耗更小。叶晖等人[7]提出ON-CRP (Opportunistic Networking Cache Replacement Policy) 机会网络缓存替换策略, 利用消息副本与不同目的节点的相关度来执行缓存替换。由节点的社会属性可找出节点的行为模式, 然后以节点群组为目标进行消息递交, 但由于单一地依靠消息与节点的关联度进行替换判断, 可能会使消息在缓存中保存时间过长, 造成投递延迟增加。
本文综合消息的全局递交率, 根据人类移动模型[8]中表现出的节点移动规律, 考察网络中递交消息副本的路由记录与全局历史缓存信息, 利用消息参数反映的各中继节点和目的节点间的相对关系提出MIPM (Message Information for Priority Management) 缓存策略。根据参数进行缓消息存队列的管理, 由已传递消息的副本计算参数与路由向量记录判断消息送达的可能性, 从而充分利用节点有限缓存, 实现消息最大的成功投递率并降低投递延迟, 以提高网络整体性能。
1 基于消息参数的缓存管理
提出基于消息参数的缓存管理算法包括缓存管理替换与队列管理两个部分。其中替换策略的核心是通过估计副本缓存参数与缓存内消息进行比较替换, 各节点根据自身情况, 结合缓存中的消息参数进行取舍判定;队列管理采用路径向量匹配排队策略, 根据节点维护的状态信息结构进行缓存队列排序管理。
1.1 副本缓存参数
在机会网络中, 网络拥塞通常是由过多消息副本造成的。选取主要影响传输效率的两个参数, 消息副本数和传递深度进行缓存管理, 通过控制消息副本数或根据消息参数变化找到传输较优的平衡点。各参数定义如表1所示。
该策略在消息副本传播时以副本的相关状态参数作为其缓存参数的计算参数, 使单个节点对任一消息i计算的缓存参数更符合当前网络的传输优化条件。缓存策略不控制消息副本转发次数的条件下, 消息i产生后会被各节点在相遇时复制并转发。当每个节点收到新的消息时, 根据副本携带的各参数来估算此消息在整个网络中大致的副本数量nt (i) , 并依此计算出在缓存内分配的优先值Uj (i) , 进而在缓存溢出时根据Uj (i) 对相应的副本做出取舍判断。
消息i缓存参数的计算表达式:
其中Uj (i) 表示消息i到达节点j时的缓存参数, pj (i) 是节点j中消息副本i的效用值。由多副本传输机制, 在任一时刻t, 对于消息i可知其副本的消息剩余存活时间越小, 则消息i在网络中停留的时间越长, 被节点复制转发的副本越多, 进而增大其成功投递率。
由文献[9], [10]可知, 在大多数的移动模型中, 任意两节点的相遇时间t服从指数分布, 或在时间上表现出类似指数衰减的曲线, 如随机路点模型[11]、随机路线模型、随机方向模型、社区模型[12], 以及在现实生活中用移动设备采集的真实路径模型[13,14]等。
假设网络中共生成了Mt个互不相同的消息, 在任一时刻t下, 节点做出判断, 有可能会将生存时间为Tt (i) 的消息i丢弃, 对于任一消息i∈[1, Mt], Dt (i) 表示从消息产生至时刻t止, 缓存过消息i的节点总数 (源节点除外) , nt (i) 为在时刻t下携带有消息i副本的节点数, 则整个网络在t时刻对全部消息的平均全局递交概率Wt由下式表示:
其中:
Lt为t时刻时网络中的节点总数由以上定义描述可知, 有nt (i) ≤Dt (i) +1。由于两节点间的相遇时间服从参数为λ的指数分布[15], 则消息i的一个副本投递失败的概率等价于此节点在下次相遇时碰到目标节点的时间大于消息剩余存活时间, 即exp (-λRt (i) ) 。
效用值uj (i) 可看作是消息副本的临界效用, 是基于消息参数而得的某一副本相对当前节点内全部缓存副本的一个评估值, 在节点缓存溢出时的最佳缓存管理策略应是替换缓存内效用值最小的副本, 即有:
1.2 队列管理与替换算法
1.2.1 入栈管理
本文MIPM算法的入栈管理中, 设节点缓存内已有n个不同的消息副本i1~in, 节点考察参数Ht (1) ~Ht (n) , 并将其按大小排序组成队列。当节点j收到大小为Si0的消息i0时, 首先判断缓存容量, 若BSj≥Si0, 则可将i0直接放入缓存队列;若BSj<Si0, 说明缓存溢出, 则读取其Ht (0) 并与缓存中其他消息副本的Ht (i) 进行比较, 若Ht (0) <Ht (i) , 则节点丢弃i0;否则将Ht (i) 值最大的一个副本移除, 然后重复上述比较过程, 直到满足BSj>Si0, 即可将i0放入缓存。
从一个消息产生开始, 每个消息及其副本都带有唯一的路由表, 用以记录此副本在网络中经过的节点。消息的路由表用一个一维数组RV表示, 记作RV=[R1, R2, R3, ..., Rn]。其中Ri (i=1, 2, ..., m) 表示此副本经过的第i个中继节点的ID。随着消息副本在网络中的复制和传递, 每到一个中继节点, 该节点即读取此副本的目的节点ID和其路由数组RV, 并将其加入自身维护的区域路由列表中, 此表大小为n×m, 不同节点的路由记录来自缓存过的副本携带的路由表。
1.2.2 出栈管理
当网络中的节点移动时, 它们相遇后可进行通信。假设某节点J碰到网络中另一节点K时, 两节点在可进行消息交换的条件下, 先获取对方的ID, 分别记作NA和NB, 然后在各自的路由列表中查询此ID。若ID存在, 说明对方曾作为网络中某条链路Ri的中继节点Riy递交过消息, 它遇见Ri内上下节点Riy+1和Riy-1的概率较其他随机节点大。再读取对方Ri的全部中继节点ID, 到缓存中匹配各消息副本的目的节点Dx, 若存在, 说明此副本到达其目的节点的链路在网络中曾经存在。同时, 依照节点活动的社会规律性, 同一链路中的各结点再次相遇的概率大于其他节点。因此可判断对方结点是潜在的高效递交中继, 即可把相应的消息副本发送给对方。若匹配失败, 说明对方节点是在本节点历史链路中首次出现, 则按消息副本缓存参数Uj (i) 高低将缓存内消息副本排序后, 发送Uj (i) 最高的副本给对方节点。
各节点相互传递消息副本之后, 副本的Rv都会自动将接收方节点的ID记录到向量末尾并更新一次路由列表。
2 仿真验证与分析
2.1 仿真环境设置
使用the ONE (Opportunistic Network Environment) 平台[16]作为网络仿真工具。路由协议使用传染病路由算法[17] (Epidemic Immunity) , 仿真区域为4500m×3400m的城市道路网, 移动模型使用随机路点模型RWP (Random Way Point) , 仿真时间为43200秒。各个节点在本地对缓存内的消息按优先级排序, 通信方式为蓝牙传输, 通信范围10m, 信道传输速率256KBit/s, 初始化消息生存时间为18000s。默认节点缓存大小为20M, 消息大小为500-1000k Byte, 产生间隔为25-35s。
2.2 MIPM策略性能分析
本小节在不同的条件下对提出的缓存管理算法进行了仿真实验。对比本文的MIPM策略和具有代表性的RO (Remove the Oldest) 策略:丢弃在网络中最长驻留时间的消息。本节主要以消息投递率, 网络消耗量和传输延迟的性能指标对算法进行评估, 仿真以上管理策略并对它们的网络性能进行比较。
当节点缓存大小从20M增加至50M时, 对比两种策略的网络投递率。网络中节点数固定为210个。从图1中可看出, 随着节点缓存空间的增加, 两种策略的投递率均有上升, 而在缓存空间5M时MIPM策略的递交率比RO策略高约154.5%, 缓存到50M时同比高约31.9%, 且在缓存大小超过25M后MIPM算法的递交率上升变化趋缓, 稳定在90%左右。
在同样的仿真设置中, 考察各策略的网络开销。如图2所示, 当节点缓存仅有5M时, 两种策略所得网络开销较接近, 且缓存在增加的过程中, RO的网络消耗下降明显, MIPM在节点缓存大于10M后即无明显下降趋势, 在200附近上下波动, 是因为算法本身的限制使得节点在碰到合适的中继节点后继续发送消息;RO策略在有足够大的缓存时会减少节点的丢包次数, 单个节点携带消息的平均时间更长, 因此其网耗相对较小, 在缓存50M时的网耗仅为MIPM的39.1%。
同样的, 在图3中当节点数量恒定为210个时, 不同算法的网络递交延迟有较大差别。当缓存为5M时MIPM的延迟约为RO策略的48.8%, 随着缓存的增加, 其递交延迟也增加。到缓存增为50M时MIPM平均延迟为RO的46.2%, RO上升58.5%, MIPM上升50%, 但在这个方面MIPM有比较明显的优势, 能以更少的时间递交信息。
在缓存固定为20M而节点数增加的条件下, 两种策略表现出较平稳的网络递交率, 从图4看出, MIPM的递交率在80%上下波动, 而RO策略的递交率在50%附近, 有下降趋势。节点数量的增加对两种算法的网络递交率并无太大影响, MIPM因在队列管理中加入消息参数信息的判断因而能让节点更有目的地投递, 使网络有较高的递交率。
同样地, 图5显示在缓存不变而节点数从100个增加到400个时, 两种策略的网络消耗也随之增大。当节点较少时, MIPM的网耗略大于RO算法, 在节点为350以上时, MIPM表现出轻微优势, 比RO的网耗低约7.5%。从图中可看出MIPM算法的网络开销在节点数变化时其稳定性不如RO算法。节点数从100个变化到400个的过程中, MIPM增加了246.2%, RO增加了1100%。
当节点数从100变为400时, 在恒定缓存20M的条件下, 对比算法的网络递交平均延迟。从图6中可知在节点数进阶增加的条件下, 两种策略的平均延迟均呈类似下降趋势。在节点数增加300%的过程中, MIPM策略的延迟下降60%, RO策略延迟下降30.8%, 而横向比较中MIPM在节点数为100时延迟为RO的60.6%, 在节点数为400时为RO的33.3%。
通过仿真实验, 本文提出的MIPM机会网络缓存管理算法相比传统策略有较高的成功投递率和较少的网络消耗和网络延迟。从整体上评价算法对网络的改善效率, 在考虑消息参数与其效用值的基础上做出缓存替换决策能比传统缓存管理策略提高网络递交率约15%至40%, 同时能达到较低的网络递交延迟。结论证明本文提出的MIPM缓存管理算法在实验条件下能有较优的网络性能。
3 结论
本文主要研究基于消息参数的机会网络传输过程的缓存管理, 通过消息参数来确定副本在网络中的投递状态, 以TTL0和Si等参数计算消息的效用值pj (i) 以评估其缓存价值, 进而节点根据pj (i) 进行缓存参数计算与执行替换策略。在队列管理算法中, 综合考虑消息与节点的相关度, 确定节点缓存的排队序列与转发顺序。最后仿真实验并对比分析了MIPM缓存管理算法的网络性能, 仿真结果显示本文提出的策略相对传统算法能较好的适应社会网络消息的投递。本算法的网络消耗在节点数变化时较不稳定, 只能在特定环境中保证较高的递交率, 且尚未考虑在现实网络中利用群组节点的社会关系和周期性相遇时间对某类特定消息的递交效率的评估, 作为进一步提高机会网络传输效率的研究方向之一。
消息队列管理 篇2
1 模型的分析与设计
本文是在JMS和XML技术的基础上建立的信息系统,如图1所示,其中JMS服务器主要包括三个模块,消息队列管理模块、持久化管理模块、安全管理模块,如图2所示。消息队列管理模块是该系统的一个模块,主要功能是有效方便的管理消息中的对列。
1.1 JMS和XML技术简介
JMS即Java Message Service的简称,它提供了Java消息服务的API,被用来支持开发面向消息的分布式计算系统。JMS的目的就是提供给消息系统客户一个固定的接口,而且与底层的消息提供者无关,这样客户端的应用程序可以在不同的机器和操作系统中移植,而且能在不同的消息系统产品之间转移。在JMS中,消息的处理是异步的,消息发送者可以发送消息而无须等待响应。与基于RPC的同步处理模型相比,JMS的这种松耦合的异步处理机制大大提高了系统的性能。
XML以一种开放的自我描述方式定义数据结构,所组织的的数据对于应用程序和用户都是友好的、可操作的,而且其本身具有跨平台性、高度可扩展性、结构化及简单易用等特性,已成为一种通用的数据交换标准。为了保持XML文档的有效性,必须明确确定文件中的信息遵守哪些结构,需要通过XML的模式来保证。以下是两种定义XML文档的模式:DTD(document type definition)和XML Schema。两者有如下区别:
1)XML Schema是XML文档,而DTD有自己特殊的语法
2)XML Schema利用名域将文档中特殊的节点与Schem说明相联系,一个XML文档可以有多个对应的Schema,而一个XML文档只能有一个相对应的DTD;
3)XML Schema内容模型是开放的,可以任意扩充,而DTD将无法解析扩充的内容;
4)DTD只能把内容类型定义为一个字符串,而XMLSchema允许把元素类型定义为整形、布尔型、日期型等其数据类型。
2 消息队列调度算法分析
消息交换在不同的企业、部门和单位有着不同的行业标准,不同性质的企业对各种的信息有着不同的需求,例如,一些企业比较注重新的产品的推广,那么它对添加这一操作比较注重,赋予该操作的权限也将比较高。因此各种不同的信息就应该分离出来,并且对它们进行统一的管理。但是这样对优先级比较低的队列是比较的不利,同时等待的时间也是一个比较重要的数据,这样就形成了一个动态的优先级的管理。该模块的功能分成两个部分:一、从XML文件中提取出不同的操作信息,将它们以不同的粒度进行封装成消息投进不同的消息队列中去。二、对不同的消息队列进行调度管理。
调度是系统资源管理的核心机制之一,消息队列管理调度策略是采用多队列排队机制,这就涉及到多种不同类型的队列进行有区别的服务,其中包括操作分类、队列管理和分组调度。分类:就是将消息中的不同的操作分离成不同的队列。队列管理:将每一种的操作以一定的粒度来处理队列中的信息,这就要求将队列中的消息分成若干组,然后对其中的一种进行调度处理。分组调度:决定下一次的调度时调度那种操作的队列。调度算法的原理:
1)最大信息处理量Umax算法
最大信息处理量算法是选择一个队列,使其单位时间内被处理的消息队列被处理,直到该队列处理完全再让其他队列进行处理。
2)轮询调度算法
这种算法循环的调度各个队列中的操作分组,就被调度上的概率而言,对四个队列,每个队列被服务的概率都是四分之一,也就是说每个队列以相同的概率占用系统资源,这种基于轮询的调度算法是最公平的。但是由于各个队列的U不同,服务U值小的队列的比重增大,那么吞吐量势必大大减小,影响到整个系统的性能。
由于该模型的自身需求,所以要兼顾到信息处理量和公平两个原则,而在不同的业务方面考虑对不同的操作的优先级的不同,这样就可以基本上解决信息交换的顺利进行。
该模块的数据流图如图3所示。
3 消息队列管理模块设计
该模块是建立在一个消息系统的基础上,是对该信息系统的消息队列进行管理,是该系统的一个构件。
1)消息队列管理模型
在该模型中包括消息解析器、添加队列、删除队列、修改队列、查询队列、调度器和处理队列。其中解析器包括两个主要的功能:解析并分离出不同的操作和将不同的操作封装成为消息。四种队列是用来接收来自解析器中的不同的消息。调度器:计算不同的队列中的优先级别,根据优先级别对队列中的消息进行调用。处理消息队列用来接收调度器调度的消息,然后系统对该队列中的消息进行处理,如图为消息队列管理模型图如图4。
2)调度算法的设计原理
本文中系统的调度算法策略主要涉及到三个主要参数:不同操作优先级别(bi)、平均等待时间(t)和信息处理量(U);
a)优先级别bi
在整个系统中,不同的操作的优先级别是一个固定的值,代表着该系统对不同操作的重视程度。添加、删除、修改和查询的优先级别分别为:bi(0
b)平均等待时间t
在一次调度时刻,调度的消息是以组(即一定的粒度n)来调度的,因此,等待时间将是
该组的平均时间。而每一个消息的等待时间为调度时的时间和进入该队列的时间之差,即T=Tk-Tm其中Tk为调度时刻的时间,Tm为该消息进入对列时的时间,因此,t=(T1+T2+…+Tn);为了确保每个队列都尽可能的被调度,当平均等待时间t越长,该队列的优先级别就越高,即队列的优先级别以平均等待时间成正比。
c)累积信息处理量U
U为该队列从某时刻起到一次调度时的总的累积信息量,例如:在某一调度决策时刻t,四个队列的累积信息处理量Ui,在该时刻每一个队列准备调度的消息量为△Ui,因此下一个调度时刻的累积信息处理量为:Ui+△Ui;整个队列的优先级别B以平均等待时间t成正比,以操作的优先级别成正比,以累积信息处理量成反比。
因此队列的优先级别为:
其中Qi(Qi
4 结束语
消息队列中间件对企业分布式应用系统的开发具有很大的吸引力,它向开发者展现了一种灵活、丰富且非常简单的通信模式。JMS提供了一组与具体实现无关的接口,各种分布式应用程序可通过这组接口来访问支持JMS的消息中间件。而随着消息交换的数据量越来越大,消息队列管理的重要性也就越来越大。现在JMS技术已得到了广泛的工业支持,有着广阔的前景。
摘要：该文介绍了JMS的基本工作原理,并在此基础上提出了基于JMS和XML技术信息交换模型的设计,并着重提出信息交换中消息队列管理模型的研究。此模型基本上能解决信息交换中信息量大且容易阻塞的问题。
关键词：JMS,XML,信息交换,信息交换模型,消息队列,消息队列管理
参考文献
[1]冯磊.JMS给中间件市场加热[J].信息系统工程,2007(1).
[2]沈良忠,黄德才.JMS和XML的分布式应用研究[J].铁路计算机用,2004.
[3]孙剑.XML数据交换标准在物流行业的推广前景[J].物流技术与应用,2005.
[4]黄忠国.分组调度算法在船闸调度中的应用研究[D].大连海事大学硕士学位论文,2006.
消息队列管理 篇3
IBM公司研发的Webspere MQ就是一款典型的消息队列产品,在消息存储转发机制基础上,更好的原语设计,更强的通信协议适配以及定制性更好的安全策略等,都使得该系列在业界应用十分广泛,成为了不同操作系统,不同网络环境之间应用通信的桥梁。
在很多关键性领域中如金融,交通管控等,往往对于消息可靠性要求较高。要做到消息不丢,不重,不错,即保证队列管理器能够同时实现数据和服务的高可用,仅仅凭借MQ无法实现,需要从底层产品入手,同时对MQ自身的参数调配,搭建高可用的消息队列。
1基础知识介绍
应用程序把消息放进队列里,然后发往另外一个队列管理器中的队列,或者等待其他的应用程序把消息读走,由于其良好的适配性,常被用于不同主机间的进程间异步化通信。它有几个重要的概念:
1)队列管理器
MQ的基础设备,作为顶级单元,它往往被用于维护和管理其他通信中使用的对象,并完成同其他队列管理器的通信。
2)消息
队列管理器使用的基本通信单元被称为消息。它分为消息头和消息主体两部分。消息头存放了消息描述符(Message Descriptor),这些内容供MQ本身使用,消息主体里面存放应用数据(Application Data),由取用消息的应用程序解析使用。
3)队列
用于存放消息,是存储转发机制实现的核心。常用的队列有本地队列,远程队列,传输队列和别名队列等。远程队列指向另一个队列管理器的本地队列。在被放入消息后,会将消息通过传输队列传递到远程的队列管理器中去。
4)通道
队列管理器之间以及同应用程序间的通信都需要使用通道。特别地,分别在两台队列管理器A和B上面建立同名的发送通道和接收通道,即可完成从A到B的通信,反向亦然。
5)监听器
监听器需要被单独定义并启动,用来监听对应端口的消息。这些消息可能是应用数据,也可能是管理请求。
图1是一般基于MQ的通信环境拓扑示意图。
图1 基于 MQ 的应用程序通信拓扑
图1的方案可以满足基本的通信需求,但是由于存在着诸如单点故障等隐患,因而无法保证通信链路的高可用性。
为了解决单点故障,MQ提出了多实例队列管理器的概念。定义多实例队列管理器,并在共享存储上队列管理器数据和日志,然后将这个信息分发给另外的挂载该存储的MQ服务器 ,就实现了 多实例队 列管理器 。 应用strmqm – x[QM_NAME]可以以多实例的主机方式启动队列管理器。后启动的一台将以standby方式运行,当主机宕机或者出现故障,其加在存储上的锁会被释放,备用机接管并启动,成为主机。一套多实例队列管理器最多同时支持两台实例同时运行。其他实例只能在有运行实例宕机后手动启动。
2高可用队列管理器总体设计方案
该方案设计拓扑结构如图3所示,本方案主要从3个层次解决单点故障问题。首先,通过多实例队列管理器来保证应用层的服务可用性。这样,在一台MQ主机宕机后,备用实例自动运行起来,继续为客户端应用程序提供服务。
其次,在存储层,应用Gluster FS服务器作为共享存储, Gluster FS采用堆栈式结构组织,封装了多台服务器的写磁盘操作为一个原子写入操作,所有写入挂载目录的请求会被转化为网络通信后写入多台服务器中,同时成功即返回成功。单台存储主机宕机后,另外的主机会根据一定的算法踢出不可用的服务器,重新组织结构并继续对外提供数据存储服务。通过这种多机冗余和强同步机制,实现了存储服务的高可用性和极高的数据一致性。
最后,在客户端应用和队列管理器之间,使用lvs和keepal-ived搭建了vip,在队列管理器完成切换后,vip会自动实现漂移和迁转,这个过程对应用几乎透明。总体方案有效地提高了服务在线率和可用度。
3方案可靠性验证实验
设计了三组实验来验证这套方案的可用性。首先部署实验环境如下:
机器A上运行应用通过vip向队列管理器TESTQMA中的远程队列MSG_REMOTE发送消息。MSGIN_REMOTE收到消息后会通过传输队列XMITMSG将消息转发至队列管理器TES-TQMB中的本地队列MSG_IN。为了统计某一故障对整体方案可用性的影响,在应用中加入统计代码,统计出现访问异常的时间。同时为了排查消息的丢失和重复投递情况,在发送的消息上打入时间戳和编号。
实验一、制造MQ单机运行故障。
手动关闭MQ主机进程,此时应用开始出现访问异常,约10秒左右,备用实例启动,并开始提供服务。最终统计在TES-TQMB中的消息数目,与发送数目相同,没有丢失和新增消息。
实验二、Gluster FS服务器单机运行故障。
在其中一台Gluster FS服务器上执行防火墙脚本,模拟其与其他机器间网络故障。Gluster FS立即停止提供服务,同时客户端程序感知故障发生,开始进入异常重试,约42秒左右,Glus-ter FS恢复服务,MQ正常接收消息。最终统计结果,收到的消息和发送的消息数目相等。没有丢失。同场景1相同,服务不可用期间,需要应用客户端做业务重试,保证消息的完整性。
实验三、制造实验MQ与目标远程MQ间网络故障.
在实验MQ主机上执行防火墙脚本,禁止其与远程MQ间数据通信,在达到队列最大深度限制钱,应用程序依然可以向实验MQ放入数据,在通信恢复后,消息被发往目标队列。如果达到接收队列最大深度,应用程序的发送请求将会抛出异常, 无法继续放入数据。
实验四、制造LVS服务器单点故障。
在VIP层制造单机宕机故障。Lvs迅速实施故障转移,备机启动提供服务,全部过程几乎在2秒内切换完毕,MQ对异常无感知,应用会出现短暂报错,之后恢复正常。
结果如表1所示。
实验结论:
该方案对服务器单点故障和通信故障灯均具有较好的容错性,可以做到服务的秒级恢复,同时提供了很好的数据一致性保证。同时,为充分解决服务瞬时不可用的问题,需要在应用客户端层做业务重试。
摘要：Webspere MQ是IBM研发的一款优秀的消息中间件产品。该产品基于消息队列的存储转发机制,为不同应用的整合通信,信息交换提供稳定的桥梁。在实际应用中,底层产品如存储器等对中间件整体可用性有很大影响。该文在如何提高消息中间件可用性方面进行了探索。
消息队列管理 篇4
消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上, 队列存储消息直到它们被应用程序读走。通过消息队列, 应用程序可独立地执行--它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。
消息队列是用来实现播出软件不同模块之间进行通信的, 目前的播控软件中在以下几个流程中应用了消息队列:
1、编单软件发送节目单后播出软件立即接到并显示发单信息;
(备注:该流程中, 编单软件先将消息发送到消息服务器的消息队列中 (队列名称在系统配置工具中进行配置) , 消息服务器端在检测到自己的队列中有了新的消息后, 就会根据该消息的类型和消息订阅情况, 判断出播出工作站的队列订阅了这个消息, 所以将该消息转发到播出模块的本地消息队列中 (默认为dbsap_local_msg) , 播出软件在检测到本地队列中有了新的消息后, 处理该消息并弹出窗口提示有新的节目单已经被发送了)
2、在播出软件中添加边播出边上载任务以及延时播出上载任务后, 上载软件可以立即添加相应的上载任务;
该流程中, 播出软件先将消息发送到消息服务器的消息队列中, 消息服务器端在检测到自己的队列中有了新的消息后, 就会根据该消息的类型和消息订阅情况, 判断出上载工作站的队列订阅了这个消息, 所以将该消息转发到到上载工作站模块的本地消息队列中 (默认为uploadmsgqueue) , 上载软件在检测到本地队列中有了新的消息后, 处理该消息并从数据库中读取对应地边播边载任务或延时播出任务添加到上载任务列表中
3、在素材管理器中添加素材同步
相关任务, 或者选择重新执行某个失败的素材管理任务后, 素材同步服务器可以立即获取并执行相关任务。
该流程中, 素材管理器先将消息发送到消息服务器的消息队列中, 消息服务器端在检测到自己的队列中有了新的消息后, 就会根据该消息的类型和消息订阅情况, 判断出素材同步服务器的队列订阅了这个消息, 所以将该消息转发到到素材同步服务器的本地消息队列中 (队列名称是在系统配置工具中配置的, Sync Message) , 素材同步服务在检测到本地队列中有了新的消息后, 处理该消息并从数据库中读取对应同步任务添加到执行列表中
4、在素材管理器中选择改变同步迁移任务的执行优先级。
该流程中, 素材管理器先将消息发送到消息服务器的消息队列中, 消息服务器端在检测到自己的队列中有了新的消息后, 就会根据该消息的类型和消息订阅情况, 判断出素材同步服务器的队列订阅了这个消息, 所以将该消息转发到到素材同步服务器的本地消息队列中 (队列名称是在系统配置工具中配置的, Sync Message) , 素材同步服务在检测到本地队列中有了新的消息后, 处理该消息并改变对应任务的优先级
5、在素材管理器中更新了某些素材的信息后, 在播出软件中弹出对话框提示素材更新信息。
该流程中, 素材管理器先将消息发送到消息服务器的消息队列中, 消息服务器端在检测到自己的队列中有了新的消息后, 就会根据该消息的类型和消息订阅情况, 判断出播出软件的队列订阅了这个消息, 所以将该消息转发到播出软件的本地消息队列中 (默认队列名称为:dbsap_local_msg) , 播出软件在检测到本地队列中有了新的消息后, 处理该消息并弹出对话框提示某条素材信息已经更新。
在所有的环节中, 消息队列在其中起了很重要的作用, 它好比信息中转站, 收集和发送各类系统中互相传递的消息, 以保证各软件及时收到指令, 正常工作。如果消息中断或大量拥堵, 那么各个软件之间将无法正常通讯, 发送的消息没有回应, 也不能接收消息, 该它完成的工作也不能完成。
系统运行初期, 遇到下面这样一个问题:
消息服务器和素材同步服务器的消息队列是在系统配置工具中进行配置的, 在系统配置中素材同步服务器配置本地消息队列为msgqueue和sysqueue, 消息服务器消息队列名为Msg Queue和Sys Queue, 有大小写区分, 但在各服务器的消息队列中查看, 它们的名称不分大小写, 实际上等于同名, 这样就造成了系统中消息错乱或拥堵。
正常情况下, 消息队列中的内容在被客户端应用程序访问以后, 会做相应的处理, 然后被应用程序删除掉, 在查看消息队列时, 各个消息队列的数量应该为“0”。由于同名原因, 消息服务器和素材同步服务器同时接收到发给两服务器的消息, 可是每个服务器只能处理自己的消息, 剩下的消息就大量拥堵在消息队列中。由于处理的和未处理的消息量具大, 占用了大量内存, 安装消息服务器的服务器内存为1.5G, 消息服务的内存占用率最高时为1.6G, 基后果可想而知。另外, 消息服务器给素材同步服务器发同步任务消息, 由于重名, 两个服务器之间不断的转发, 造成许多同步任务不断的反复执行, 正常的任务就会受到影响。后将素材同步服务器的队列名设置为Sync Message和Sync System, 解决了上述问题。
消息队列管理 篇5
1 消息队列
在Windows系统中应用程序之间的通信有这么几种:内存映射、消息队列(Microsoft MessageQueue,以下简称MSMQ)、套接字、命名管道等。MSMQ是Microsoft的应用程序之间通信处理技术,彼此相互通信的两个应用或者进程可以在同一台主机上运行或者在网络中应用,甚至是处于间断连接在一起的不同机器上。在Windows系统中通过MSMQ组件使的两个或者多个应用程序之间相互通信,MSMQ为基于服务器的应用程序组件之间的进程间通信提供了强大灵活的机制,MSMQ有以下优点:
1)MSMQ具有故障保险特性。在两个进程间或应用程序之间传送定义即将发送的消息是数据基本单位,传送的消息可以非常简单,譬如:只包含文本字符串。MSMQ是在应用之间传输消息的存放消息的容器,应用程序将消息发送到队列中,MSMQ作为应用通信的中转站,负责将消息从它的源中转到目的应用程序,MSMQ在此过程中的主要作用是提供消息路由且保证消息的正确传递;若发送消息时接收者暂停运行或者停止运行,则MSMQ会保留消息,直到可以成功地传递它在,这样可保证应用程序消息到达它们目的地。
2)MSMQ稳定性和消息优先级。应用发出的消息存放在MSMQ中等待应用合适的处理,所以对于需要通信的数据存放在队列中是非常稳定;对于紧要的消息或者重要的消息需要提前接收处理,那么MSMQ则有优先级之分来满足各种类型的消息,所以为了应用程序能够稳定的运行,要分析清楚其消息的轻重缓急,一旦确定消息的优先级之后,使用MSMQ的优先级机制保证应用程序的响应时间。
3)MSMQ安全性。MSMQ技术使用Windows操作系统安全机制提供消息队列的访问控制,并且对使用消息队列的应用程序提供验证及加密功能。具体情况具体分析,使用MSMQ是根据使用的方式不同可以分为以下几个队列:公共队列,在整个MSMQ网络中复制,可被网络中的所有主机访问,适合使用在消息群发的应用通信;私有队列,不能在个网络中发布并且只能存在本地计算机中,私有队列的访问必须知道队列的完整名称。
4)MSMQ异步接收。MSMQ的通信在属于异步,发送消息和接收消息均有不同的进程完成。接收消息的应用程序进行异步接收操作,可以调用适当的异步方法,不阻塞当前进程。MSMQ通过异步接收方式大大提高系统运行的效率,所以使用异步接收消息非常重要。
5)MSMQ脱机操作。应用程序通信时发送的消息,可被发送到临时队列中并保存在那里,一直等到被另外应用程序成功地接收。因为某种原因所访问的队列不可用时,应用程序可以继续执行,就像消息已经得到处理一般,一旦网络恢复连接时消息能够正确的被传递。
2 JSON
JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式。它使得人们很容易的进行阅读和编写。JSON是轻量级的文本数据交换格式JSON独立于语言JSON具有自我描述性。例如下格式:
JSON与XML最大的不同在于XML是一个完整的标记语言,而JSON不是。这使得XML在程序判读上需要比较多的功夫。主要的原因在于XML的设计理念与JSON不同。XML利用标记语言的特性提供了绝佳的延展性,在数据存储,扩展及高级检索方面具备对JSON的优势,而JSON则由于比XML更加小巧,以及浏览器的内建快速解析支持,使得其更适用于网络数据传输领域。
3 使用MSMQ与JSON实现应用程序间通信
Windows应用程序间通信如图1所示,应用程序1和应用程序2通过MSMQ来发送、提取JSON格式的消息。使用MSMQ完成应用程序间通信,分为如下几个步骤。
1)安装MSMQ。在控制面板页面打开添加程序,找到windows组件选中MSMQ组件然后点击确定就可以完成组件的安装,并且可以有两种模式的安装分别为:工作组模式和域模式。当安装程序没能够发现一台提供目录服务的MSMQ的服务器的时候,此时MSMQ只能安装成为工作组模式,同时此机器安装的MSMQ只能够创建私有队列与创建与其他运行MSMQ的应用程序的连接。
2)配置MSMQ。打开计算机组件找到MSMQ,可以创建专用队列和公用队列,例如:在专用队列下创建MSMQDemo队列
3)编写代码。Windows操作系统已经提供了封装好的MSMQ类MessageQueue。在编写程序时使用MessageQueue类的构造函数传递一个消息队列的名称,或在计算机上创建新队列。在调用发送、接收消息队列时,需要将MessageQueue类实例与指定的MSMQ连接起来。
MessageQueue类在程序中可以使用同步操作和异步操作。消息队列同步操作,接收函数创建新的线程且指定的时间间隔轮询消息的到达。异步接收的操作使得应用程序在消息到达之前继续执行其他任务;一旦消息到达通过使用回调函数以及状态对象进行接收消息操作。在编写程序之前需要导入System.Messaging命名空间。以下是发送消息部分代码:
4 结束语
消息队列管理 篇6
上海市社会保险业务管理信息系统(简称“上海市社保信息系统”)是上海市劳动和社会保障管理信息系统[1]的子系统之一,为上海市劳动和社会保障事业发展提供了强有力的技术支持。然而随着社保业务规模的不断扩大、服务对象的不断增加、信息流通的日益频繁,系统负荷与系统性能之间的矛盾逐渐显现。同时随着社会保障工程建设的逐级推进,市民对窗口服务的质量要求越来越高。窗口服务质量很大程度上依赖于信息服务的全面、迅速和便捷,因此在完善该信息系统服务功能的同时提升系统的高效性、智能性和个性化服务体验应是必然的发展方向。
当前,上海市社会保险人均业务变更量已达全国平均水平的3倍,柜面办事拥堵的矛盾日渐显现。每月27日至次月4日社保窗口停止对外服务,用以数据库系统记账、扣缴及支付数据文件生成等的成批处理,以及将日常前台接受的变更信息进行成批后续处理。作为服务支撑平台的社保业务管理信息系统,若能祛除1/3的成批数据处理时段,让窗口服务天天开启,同时简化办事步骤、提高操作效率、减少窗口等待,显然可以进一步提升社保窗口服务的质量。
0racle高级队列技术AQ(Advanced Queue)[2]提供异步通信功能,能够改变当前系统中一部分不必要的面对面同步通信响应的应用模式,将部分人工点击转化为自动处理操作,分前台任务到后台处理,均衡多个服务器的负载,开拓分布处理的空间,从而提升系统性能,并充分发挥各时间段、各服务器的效用,进而提高为窗口服务的功效。
1 Oracle AQ的技术特点
Oracle AQ是一种能将应用程序处理工作有效地划分为前台任务和后台任务的处理技术,不同应用程序和用户之间能够通过消息(即符合某种语法的消息或数据)队列进行异步通信。它通过存储消息、消息排序、传播消息的同时转换消息的表现格式、最后按时按需向一个或多个应用程序提交消息来发挥并行处理作用。应用Oracle AQ的通信功能,能够实现任务转移的分布式应用处理以平衡前端计算机的负荷、充分发挥后台服务器的性能,均衡多服务器的效用。此外,还能够延迟无需立即交付的任务,或将任务按优先级别重新排序,保障任务按响应速度要求排序处理,并且能够将一批任务存入队列定时异步处理。
1.1 Oracle AQ的特性
0racle AQ技术构建于Oracle事件流[3]的统一基础架构,是集成于Oracle数据库的消息队列。它自动继承了所有Oracle事件流的处理功能和Oracle数据库处理功能,因而可使用数据库所有的固有管理功能,继承了数据库管理和访问的所有优势,如可靠性、完整性、高可用性、安全性和可伸缩性。
1.2 Oracle AQ的入列数据类型及入列方法
Oracle AQ支持RAW,Oracle object和Java Message Service三种类型的消息,甚至支持AnyData[4]消息队列,可以同时存储多种数据类型的消息,并能用PL/SQL[5]表达式将原始数据模式在入列/出列过程的任一环节转换成各种数据模式。AQ提供了分布式应用的非同期集成,提供了多种消息入列的方法。不论是通过应用和工作流程生成的、从重做日志内隐式捕获的、或通过数据库触发的事件均可被捕获于队列,其延期功能还允许将稍后日期内可以看到的消息入列,还可为需要立即处理的消息提供通知系统。
1.3 Oracle AQ的出列方法
Oracle AQ可以通过PL/SQL、Java或C来访问,可以通过Oracle Net Services (SQL*Net)、HTTP(S)和SMTP在远程节点之间传播消息,甚至可以通过消息网关与非Oracle的消息管理系统(如IBM MQ Series)[6]相集成。
1.4 Oracle AQ的传播模式
Oracle AQ支持两种传播模式:(1) “点对点”[2]的单一消费者模式,即发送方和固定接收者通过一个共同队列来交换消息;(2) “发布/订阅”[2]的单点对多点模式,即消息可以被多个接收者使用,并可进一步细分为接受无限制的“广播”和明确订阅者的“多播”两种传播模式。
2 采用AQ提高社保信息系统的处理性能
2.1 应用AQ的异步通信功能实现消息分布式处理
很多系统应用可分为需立即执行和可延迟执行两种。将可延迟执行的任务从前台请求处理中分离出来排入队列,然后由队列传播到后台,甚至交由远程服务器处理,可以大大释放前台机器的计算资源,缩短前台系统在线处理的等待时间。AQ的可存储性和传播性允许系统自由分配任务执行的资源、时间和空间,从而在计算资源、时间和空间上均衡整体系统的负载,充分发挥系统性能。
上海市社保窗口服务单位的主要服务是接受单位、个人等服务对象的社会保险业务的登记和变更等信息。其中,缴费对象转入转出,缴费基数修改和缴费或支付方式修改等绝大部分数据处理无需立即应答,仅需存入电脑为申报结算、记账、隔月缴纳支付等后续服务做准备。当前系统在窗口办理上述业务时立即将变更消息写入数据库的变更信息表、到月底再依据变更信息表生成最终数据进入各相关数据库表。采用中间数据库表存储待处理数据信息的处理模式尽管比窗口在线办理时直接写入最终数据库表(一般是多个表,数据庞大,索引较多)要节省前台等待时间,但前台依然存在等待变更信息写入中间数据库表的时间,同时还需系统月末成批处理大量数据,生成了系统必须停止前台服务的性能瓶颈。
应用Oracle AQ技术可保障登记和变更数据入库的处理滞后分布进行,前台无需在线等待处理结果,因此在滞后的处理中可把信息写入中间数据库表的原处理模式改成滞后直接写入最终相关数据库表的处理模式,即将登记或变更信息的消息存入队列,由之传播到后台甚至一指定的服务器,让系统根据配置的处理方式自主利用系统计算资源空余间隙(如午间休息、晚间闲置时间)分布处理消息并直接生成最终数据存入相关数据库表。
采用Oracle AQ的异步通信功能实现消息滞后分布处理的优势是:(1) 窗口服务现场可把信息写入数据库变成把信息处理任务以某种语法组织后缓存在存储空间以节省数据库访问I/O的等待时间;(2) 非必须立即执行的任务转由系统分时、分机处理,充分利用了系统资源的闲置时间;(3) 免除了中间信息数据到最终数据的再处理,能够有效缓解月末关闭窗口服务用于大批量数据后台处理的性能瓶颈。
仅以“单位缴纳银行扣款回盘接收”业务处理为例:现在操作员通过窗口在线对每一个回盘文件面对面处理,从输入回盘数据文件名称到文件读取处理完毕,操作员必须全程等待,大文件须等待十几分钟,每天要处理的文件少则几个多达几十个,操作员一般需在机器前守候多个小时。启用Oracle AQ,窗口操作仅需随时将当即收到的回盘文件名入列后即可离开机器,后续任务全部交由出列程序自动执行。盘中数据入库的业务处理可以依据系统状况立即本服务器后台处理,也可将消息传播到其它服务器进行分布处理,或者定时到夜间由系统自动成批处理。同时,因为上述业务处理无需面对面答复因而没有了响应时间的要求,所以可以在接收回盘数据时将据此数据生成的实记账数据(原本是月底成批处理的)一并生成。
文件读取、记账模拟过程的出、入列代码如下:
--出列:即对队列中的文件依次读取数据并依据数据生成实记账,
2.2 应用AQ的分级排序功能实现系统自动有序处理
Oracle AQ支持消息的先入先出排序和基于优选条件的消息排序,并提供了多种方法支持消息排序,同时支持复杂调度。透明于应用的Oracle AQ系统自动有序地管理通信和分布式应用,因而仅需排列好待处理消息的先后顺序、优先级别,布局好有效调度[2],就能由系统自动发挥其处理性能。
上海市社保信息系统在全市各区县都部署有在线服务窗口,各区县的业务办理量不同导致个别区县窗口服务对象排队较长。应用Oracle AQ的分级排序功能,将个别处理较为繁复的业务入列,并依据区县业务量的大小赋予各区县业务不同的级别,由系统依据级别优先的原则自动排序处理队列任务,这样可让业务量大的区县的业务获得优先处理,以均衡各区县服务对象的等待时间。
上海市社保信息系统每月承担着大量的有严格业务流程要求的批处理任务。当前的系统将月处理分成了多个软件程序,由软件程序代码判断前序任务是否完成来严格执行业务处理流程,操作人员也必须依据业务流程按次点击应用软件并全程等待所有软件的完成。因为批量数据月处理是个无界面输入的处理过程,所以完全可以将面对面逐步完成处理的方式全部改为系统自动有序处理,即将各成批处理过程入列,由队列排序功能自动控制任务的执行顺序,从而免去人工点击触发,并可监测队列执行情况随时查询执行进度。
采用Oracle AQ的分级排序功能有如下优势:(1) 利用Oracle自构的管理能力显然比编码控制更能高效地发挥系统性能,并能免去许多判断过程;(2) 将排序设计从软件详细设计提高到了系统分布式处理设计层面,更全面更直观更易于维护;(3) 队列对处理顺序的封装使得软件代码简洁并可减少编写失误;(4) 当业务流程变动时,仅需变更入列过程的优先级,在增加或减少任务环节时仅需增减入队的任务,从而减少了软件程序的修改,使系统维护更高速便捷。
建立排序顺序的代码如下:
2.3 结合AQ与REGISTER实现一对多的异步并发处理
Oracle AQ如同一棵消息树,一个根上分叉出的多根树枝均能开花结果。将Oracle数据库的AQ的通知功能与ORACLE的REGISTER注册功能相结合,即可发挥队列消息增加的通知功能,引发多个后续事件的自动异步并发响应。
如今,上海市劳动和社保已集成于一个数据库系统,上海市劳动和社会保障管理信息系统与工商、医疗、公安、公积金管理和银行等系统都有业务联系。而服务对象的一个变动往往会同时引发劳动、社保、医疗等多个系统的同步变动。现在每个服务对象必须跑到各个服务窗口办理相关业务,不仅给服务对象带来劳累,还可能因业务的不同时办理、甚至遗漏办理而发生错误。
应用Oracle AQ技术将消息入列,利用其“发布/订阅”模式以及可通过多种方式传播到远程节点的特性,将消息传播到多个须接受该消息的节点,然后立即触发各节点的出列过程,从而实现异步并发处理。如此操作,在实现信息共享的同时,简化了办事步骤,减少了人工操作,提高了服务性能,减少了人为错误的发生。
例如,单位到工商登记后,工商系统即将消息入列,传到劳动系统触发劳动系统的单位登记出列、同时传到上海市社保信息系统触发社会缴纳单位登记出列。
信息入列后立即触发出列操作的代码如下:
2.4 结合AQ与DBMS_SCHEDULER实现周期性定时消息批处理
将Oracle数据库AQ的存储功能与ORACLE DBMS_SCHEDULER.CREATE_JOB执行任务调度功能相结合,即可指定系统自动按周期、按时、按序执行任务,从而实现无需人工干预的定时自动化的批处理操作。
上海市社保信息系统现有大批量的无界面输入的成批数据处理,现在基本都集中在月底处理,而在线面对面的窗口运作模式让操作员不得不加班加点地守在机器前,在点击一个“开始”后、长时间地等待系统跳出“任务完成”,然后再开始下一个触发与等待。
应用Oracle AQ技术将成批处理以procedure写入数据库,按处理步骤将处理过程赋予不同级别后入列,将出列操作定周期、定时,系统即可周期性地自动执行出列处理。当前社保信息系统的月处理中的多个步骤均可采用此方式分散到日常服务日的夜间周期性地定时地执行系统自动处理。
采用Oracle数据库的AQ机制执行周期性定时批处理能够有效减少人工操作,分散处理时间,充分利用夜间、休息日等系统闲置时间执行数据的批处理。
周期性定时执行批处理出列代码如下:
3 应用AQ时需同步考虑的几个技术问题
3.1 安全性
由于Oracle AQ继承于Oracle数据库,因此它具备了数据库的优点,信息能被持久稳固地保存,并直接受益于Oracle数据库所有的高级安全特性和灾难恢复功能。当网络、计算机或应用发生故障时能存储消息、延缓请求处理。并可以使用 Oracle Enterprise Manager等数据库开发管理工具来动态监测队列情况 。
Oracle数据库的安全性特征确保了只有被授权的用户才可以访问重要数据,只有被授权和认可的互联网用户才可以通过互联网进行消息队列操作。
3.2 可管理性
数据库的管理模式给系统管理人员提供了一个方便快捷的管理平台,集成于Oracle数据库的AQ使得管理者可以如同使用表记录一样增减队列中的消息,用标准的SQL语句访问消息信息(包括消息的属性、历史消息、消息负载)。同样可以对消息进行审计和跟踪,甚至可利用索引优化消息管理。
3.3 扩展性
Oracle AQ能将消息与处理相分离,接受消息(入列)与处理消息(出列)互不干预、独立处理,从而便于软件变动。
Oracle AQ为开发和集成分布式应用提供了一个可扩展的技术框架。许多应用的集成都是通过一个分布式网络集线器和Oracle 服务器的演讲模式[6]作为网络集线器来完成的。Oracle 数据库的分布式应用通过相同Oracle数据库服务器的网络集线器上的队列来进行通信。Oracle 扩展框架允许多个应用共享同一个队列,消除了追加新的队列以支持新应用需求的麻烦。
Oracle AQ提供了一体化的集成数据库和消息队列系统,数据库和消息队列系统共享着相同的运转模式(相同的数据类型,相同的安全性和相同的事物处理模式),所以队列和程序可以实现数据、过程等多种共享和互通。同时Oracle AQ提供了多种消费消息的方法,自动适用功能允许用户调用其指定的行动来处理消息,消费与服务之间是一脉相承又松耦合的,有利于应用系统扩展。
4 结 语
队列和消息分布式定时批处理技术,目前在国内外一些基于企业内部网的计算机在线生产系统中已得到成功应用,类似的第三方软件产品已有多家成熟的提供商,如IBM,MS、BEA和Oracle公司等。软件技术如同工具,其优势的发挥程度取决于使用者的创造和实践。
本文研究、分析和提出了采用Oracle AQ技术框架实现上海市社保信息系统的处理性能提升的应用设计。文中详细描述了Oracle AQ在实现消息分布式处理、自动有序处理、异步并发处理和周期性定时批处理方面的技术路线,并给出相应的代码。本文给出的代码均通过测试,由于上线应用需涉及到整个系统计算资源的调整和业务处理部署,因此实际应用效果有待实际检验。
参考文献
[1]上海市劳动和社会保障管理信息系统—综保转城堡信息确认平台所使用说明(版本1.0)[OL].http://www.12333sh.gov.cn/zbzb/zczc/zbcb.doc.
[2]Oracle公司.Oracle Streams Advanced Queuing User’s Guide11g Re-lease2(11.2)[M].2010.
[3]Oracle公司.Oracle Streams Concepts and Administration11g Release 2(11.2)[M].2011.
[4]德什潘德.Oracle Streams11g数据复制[M].梁峰,王晓海,译.北京:清华大学出版社,2012.
[5]Oracle公司.Oracle Database PL/SQL Packages and Types Reference 11g Release2(11.2)[M].2011.