Ftp 用于文件传输的IBM MQ

我们面临一个选择，即使用IBMMQ而不是SFTP进行文件传输。我听说过这种方法的优点，但我从未见过有人真正将其用于大文件

所以主要的问题是：IMB MQ处理大文件（高达100 MB）传输的能力如何？它稳定吗？它是从大型机到UNIX服务器的，如果有关系的话

---

非常感谢。

我使用MQ处理的文件大小高达8GB，没有任何意外。您必须为MQ分配足够的空间来管理它们，但这是可行的。

供应商已经在消息传递系统（如WebSphere MQ）上进行文件传输超过12年了。我没有使用IBM产品。然而，直到最近，我才知道IBM转售了Metastorm的产品（在该品牌下），最近才以第一代产品进入市场

我一直看到处理TB大小的文件；跨WebSphere MQ分解消息并执行缓冲区确认，以避免消息队列溢出或不得不执行大量MQ管理

与SFTP相比，使用消息传递系统进行文件传输的其他值得考虑的因素包括：

前后数据移动处理-作为一种网络传输，SFTP移动数据（通过WebSphere MQ的文件传输产品也是如此）。要进行移动前或移动后处理，您必须编写自己的监控、触发、错误处理等。消息传递上的文件传输领域的成熟供应商为您提供现成的基础设施。根据您的应用程序，它们也可以提供帮助

审计跟踪-SFTP通常提供系统级日志记录。通常情况下，通过MQ提供文件集成的供应商具有更大的审核功能，包括数据移动前和移动后的处理。一些供应商还提供安全的基于web的系统，以便向授权用户公开某些集成

异常处理–SFTP将提供同步错误消息，然后根据这些消息编写错误逻辑代码。通过MQ提供文件集成的供应商通常提供异常功能，从“队列上有一条消息表明发生了问题……祝您好运”，到内置集成到基于Web的控制台甚至BPM系统

将文件传输视为一项服务——通常情况下，文件传输是更大业务流程的一部分。一些供应商利用这一点来链接文件传输，甚至让他们与以人为中心的流程协作，在点到点文件传输的上下文中提供端到端的可见性。此外，使用消息传递系统进行文件传输有助于将组织转移到更实时、消息驱动的方法

---

我希望附加的细节能在您的评估中提供一些细节。祝你好运

MQ本身提供程序之间基于消息的通信。您不能直接使用它来传输文件。人们谈论“通过MQ发送文件”通常意味着他们将自己编写程序，以便从文件读取、通过MQ发送、从MQ接收并写入另一个文件。起初，这听起来微不足道，但如果您希望它变得健壮，它很快就会变得非常复杂。不推荐

如果您想让MQ参与文件传输，您应该做的是使用MQ上的一种文件传输产品。有许多成熟的产品，我几乎一无所知，还有IBM自己的一个新产品（“Websphere MQ File Transfer Edition”），该产品正在积极开发中，最近发布了一个更新版本（7.0.1）

---

为了回答您的具体问题，我个人使用WMQFTE将1000GB的文件从AIX机器传输到Windows机器，因此我认为您的“大”100MB文件不会有问题：-）。我对大型机的参与不多，但它在很大程度上是FTE的核心平台。

在前面的一个答案中，有以下陈述：

人们谈论“通过MQ发送文件”通常意味着他们将自己编写程序，以便从文件读取、通过MQ发送、从MQ接收并写入另一个文件。起初，这听起来微不足道，但如果您希望它变得健壮，它很快就会变得非常复杂。不推荐

理论上，最好是“通过MQ发送文件”，因为当接收者从队列中获取（读取）文件时，您将收到一条确认送达（CoD）消息。另一个好处是，当收件人从队列中获取（读取）文件时，该文件将自动从队列中删除

您可能知道MQFTE是否提供上述（或类似）服务吗？

Capitalware是这里的一个选项

---

也是可以考虑的选项。 非常感谢！这正是我想要听到的。谢谢你的信息，但大部分我已经听说或读过了。我真的对我问的问题很感兴趣。你说的是真的，我也看过这个文件传输版。当然这是最好的解决办法。不幸的是，我必须在相当僵硬的环境中工作，在这种环境中，即使增加MQ消息的最大大小也是一个相当大的问题。安装新产品不太可能获得批准。谢谢。@真是无名小卒：增加MAXMSGL是一个大问题，这是有充分理由的。很难或不可能调整任何异步消息以同时处理非常大和非常小的消息。您将增加MAXMSGL视为一种无成本解决方案，并得出结论认为FTE由于价格原因机会较小。但对于除了最普通的用户以外的所有用户来说，像FTE这样的产品实际上比试图将100MB的文件塞进一条经过调整的小得多的消息管道中的单个消息更具成本效益。关于这方面的更多信息：是的，FTE中有类似的功能，尽管它不依赖于COD。根据传输的启动方式，发送方可以等待传输完成，也可以订阅主题以接收传输的状态消息。