若何得到消息?操纵JMS技术作为数据复制的办理策划[Java编程]

后台

在考虑消息传送办理筹划时,您大概会想到一个通过远程消息调用机制来集成两个差别利用程序的系统.普通来说,关于不常通信的分布式实体以及数据传输量不是很多这样的情形,常常利用这种耦合.较经典的示例是,衔接到异构后端和进口的同构接口,这些后端和进口指派举行用户恳求的后端处理,然后为终究用户表示而对那些恳求举行重新格局化.

消息传送办法中的大众线程一向有这样的假定:固然消息传送办理筹划在系统之间供应结实、高度可用的通信,但它基本上效率很低,只用来作为在无法避免与外部系统通信时的最后一种手段.在呈现远程办法调用（RMC）时关于消息传送的这种概念就开始风行一向到呈现了更现代的象 CORBA 和 DCOM 那样的消息传送办理筹划,并且,普通所利用的消息传送只范围于办理几类问题.

目标

在过去的十年中,人们对分布式系统需求有了更深化的理解.新兴技术（象 Java 和 .NET）已经包含了代码分布来作为它们基本编程模子的一部份.通过这样做,这些技术已将高度可用性和容错性融入到消息传送中,同时鼓舞那些供应办理筹划的供应商拜托一些系统,这些系统在更广范围的问题上考虑性能.

近来我们公司被要务实现文件分布和复制的办理筹划,在从前这样的筹划需求集成安全的 FTP、数据库复制和别的一次性办理筹划的定制系统.我们没有一味地用心按照定制开辟的道路行进,而是研究了将最新的消息传送办理筹划利用到这个问题的大概性.我们发现 JMS 不但为信息传送供应必要的底子构造,并且它还能处理我们客户要求的、与服务质量、安全性、坚固性和性能有关的全部底子构造问题.本文描写了我们团队面对的挑衅,以及 JMS（以 MQSeries 的情势）若何让我们满意并超越客户的要求.

问题

我们的客户面对一个庞大的分布式数据难题,在全国范围内有很多呼唤中央,在全国各地的呼唤中央里接线员要记录与客户之间的交互.必须快速坚固地在远程数据中央为这些记录成立索引并存档.成立索引和存档的存储历程不能影响接线员的系统记录和存储接线员正在与客户交互的信息的本领.该客户已经有了一个包含组合起来的代码、VPN 和别的技术的系统.但是,现有的办理筹划远远达不到性能和坚固性上的目标,并且它是一种拙劣的技术,难以理解并且保护费用很高.

在开辟替换客户原有系统时,我们考虑了 JMS 和多种非 JMS 的办理筹划,特别是那些基于 FTP 和安全复制（SCP）的办理筹划.但是,非 JMS 办理筹划有两个主要缺陷:

它们关于安全性方面的缺陷一筹莫展.

它们供应的底子构造只实用于实际的数据传送,而关于处理坚固性、容错性、安全性、平台独立性以及性能优化等问题,需求定制开辟来办理.

我们团队最后得出结论,关于增添这些额外的特点所需的开辟工作是让人望而却步的,因此我们决意选用 JMS 办理筹划,它可以摆脱这些问题.

办理筹划

我们开辟了一个基于 JMS 的系统,它:

为已记录的多媒体文件供应坚固存档

支持可扩大性,可以使多个数据中央接纳文件

支持对别的数据范例举行存档

我们这里正谈论的文件比从前那些触及消息传送办理筹划的项目中传送的数据还要大（50K - 500K）.我们第一个任务是确保数据大小不会影响 JMS 办理筹划.通过测试系统传送各种大小的消息有效负载时的性能,我们评价了包含 IBM MQSeries 在内的很多 JMS 办理筹划.后果显示:经过得当配置,大小到达 1 兆的消息不会对整个系统性能产生明显影响.因为常识认为消息传送办理筹划只实用于按期的、小的有效负载,所以我们的后果是一个庞大发现.我们持续解析系统的体系构造（图 1 中概述了此体系构造）,它可以供应客户需求的安全性、高可用性和坚固性.

图 1. 高级系统体系构造

现有的底子构造在每个客户机上有一个系统,当接线员与用户之间举行交互时,它成立多媒体文件,以此作为呼应.此外,还需对这些文件举行存档.我们的系统启动一个进程（运行在每个机械上）并在已知目录中查找这些文件.当检测到新文件时,进程将它们打包成 JMS 有效负载并发送到此中一个数据中央的 JMS 服务器以便传送.一旦 JMS 服务器确认收到,则除去发送方中的这些文件.JMS 服务器将该数据传送到数据中央内的一个可用处理程序上,举行存档.

　　以上是“若何得到消息?操纵JMS技术作为数据复制的办理策划[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：