消息队列是消息传递中间件解决方案的一个组件，它使独立的应用程序和服务能够交换信息。
消息队列存储应用程序为其他应用程序创建的“消息”或数据包，以便按其传输顺序使用，直到使用应用程序可以处理它们。这使消息能够安全地等待，直到接收应用程序准备就绪，因此，如果网络或接收应用程序出现问题，消息队列中的消息不会丢失。
这种模型称为异步消息传递，可防止数据丢失并使系统在流程或连接出现故障时继续运行。这使得开发人员能够将流程和应用程序分开，保持其通信独立和事件驱动性，从而使架构更加可靠。
消息队列可在多种部署选项的消息传递解决方案中使用，包括优化的物理设备、云服务、大型机和软件。
在云端保持清醒头脑
获取每周 Think 时事通讯，了解有关在 AI 时代优化多云设置的专家指导。
消息队列解决方案被广泛应用于各行各业。它们为开发人员和系统管理员提供了多种益处，包括：
- 可靠的消息传递：使用消息队列可以确保应用程序之间的业务关键型消息不会丢失，而且这些消息只会传递给收件人一次。有了这项功能，就不需要额外的重复数据删除或丢失预防逻辑了。
- 应用程序间连接：一些消息队列解决方案可以处理应用程序与服务之间的消息加密、事务性以及其他通信方面的问题。这简化了应用程序开发并使相异的架构可以协同工作。
- 多功能性：消息队列解决方案可以支持多种语言，例如 Java、Node.js、COBOL、C/C++、Go、.NET、Python、Ruby 和 C#。它们还可以支持多种应用程序编程接口 (API) 和协议，包括 MQTT、AMQP、REST 等。
- 弹性：异步消息传递可确保应用程序特定的故障不会影响系统。如果系统中的一个组件停止，则所有其他组件都可以继续与队列交互并处理消息。这降低了整个系统的稳定性受到一个部分故障影响的可能性。
- 提高安全性：消息队列能够识别和验证所有消息。在某些消息队列解决方案中，可以将它们设置为加密静态、传输中或端到端的消息。这有助于提高应用程序和基础设施的整体安全性。
- 集成文件传输：某些消息队列解决方案包括其他功能，例如传输文件的能力。这可以用作使用此类解决方案的企业中 FTP 的替代方案。
当今企业的算力环境复杂且高度分散。通过提供单一、强大和安全的共享消息主干，消息传递技术可以更轻松地集成不同平台上的应用程序和服务，从而防止数据丢失，并确保系统即使在连接不稳定的情况下也能继续运行。
消息队列非常适合将内部部署的后端系统与云服务集成在一起。在云架构中，应用程序通常被分解成独立的小组件。这样就更容易设计和编码，也更容易管理它们的性能。消息队列使这些基于云的解耦应用程序能够相互通信或与内部系统通信。
消息队列可以提高架构弹性，因为消息可以具有持久性。这意味着它们将存储到磁盘，直到接收消息的服务确认处理为止。消息队列可用于需要高度安全性、容错性和准确性的场景，例如金融交易处理、航空旅行预订或更新患者医疗记录。
消息队列还可用于使驻留在不同云（无论是公有云还是私有云）中的应用程序和系统进行通信，即使它们位于不同国家或地区甚至远隔大洲。使用消息队列可以提高容错能力，并可防止数据在地理位置和技术都不同的系统中重复或丢失。由于系统内的每个服务都是独立的，或者在逻辑上与其他服务分离，因此，如果其他服务或应用程序出现故障或停滞，相关服务仍可以继续运行。
消息队列适用于不同应用，例如移动设备、IoT 和传统交易系统记录。它们还支持各种平台，例如虚拟机和容器，并可实现旧版应用程序与当今最新解决方案之间的整合。
消息队列与发布/订阅的对比
消息队列使用点对点消息传递模式，在该模式中，一个应用程序（称为“发送者”）向队列提交消息，另一个应用程序（称为“接收者”）则从队列中获取并使用消息。发送者和使用者之间存在紧密耦合的一对一关系，并且每条消息只能使用一次。
如果您的应用程序需要将消息分发给多方，则可以组合多个消息队列，或者使用发布/订阅 (pub/sub) 消息传递模型。
在发布/订阅消息传递中，生成消息的应用程序称为发布者，而使用该消息的应用程序称为订阅者。每条消息都会发布到一个主题，订阅该主题的每个应用程序都会获得发布到它的所有消息的副本。
大多数消息传递中间件解决方案都支持消息队列（点对点）和发布/订阅消息模型。
消息队列与消息总线的对比
消息总线是一种企业服务总线 (ESB)，它允许服务随处访问数据，同时确保它们在分布式系统架构中保持解耦和独立运行。当使用消息总线时，所有服务或应用程序必须共用通用数据类型、通用命令集和通用通信协议（尽管它们可能用不同的语言编写）。使用者可以决定如何使用信息。
如果解耦的应用程序要通过消息总线进行通信，则必须转换消息以使其归属于同一类型。相反，消息队列可传输各类消息，无论其类型是否相同。
消息队列与网络服务的对比
应用程序可以直接通过基于标准协议（例如简单对象访问协议 (SOAP) 或 HTTP）的 Web 服务或 API 进行通信，而无需通过消息传递中间件。Web 服务广泛应用于分布式系统中，其相对简单且易于实现，使得其在某些用例和场景中成为消息队列的可行替代方案。
但是，与消息队列不同，Web 服务无法保证消息传递。如果服务器或连接出现问题，则必须构建在客户端中处理错误的能力。Web 服务还缺乏发布/订阅分发模型。消息中间件提供了更高的容错能力和更好的处理大量流量或活动暴增的能力。
要了解更多有关何时使用 API、何时使用消息传递或何时同时使用两者的信息，请参阅“API 和消息传递简介”。
消息队列与数据库的对比
在某些情况下，数据库可以替代消息队列。不过，它们的用途不同，在大多数情况下不能互换。数据库最常用于存储目的，支持反复访问相同的信息。消息队列不能用于存储。一旦信息被使用，就会从队列中删除。
在数据库中设计类似消息队列的功能切实可行，但它需要大量的编码工作和知识。数据库只能用于复制简单的队列结构，但无法扩展以适合大型应用程序。
有关数据库及其功能的更多信息，请参阅“数据库环境简要概述”。
如果您是开发通过 IBM® MQ 进行通信的应用程序的新手，以下教程将会有所帮助：
这些额外资源将为您提供更全面的概述：
资源
AI 驱动的自动化可在 API、应用程序、事件、文件和 B2B/EDI 方面扩展敏捷性。
通过 IBM 集成解决方案，连接应用程序和系统以快速安全地访问关键数据，从而释放业务潜力。
利用 IBM 的云咨询服务解锁新功能并促进业务敏捷性。了解如何通过混合云战略和专家合作共同制定解决方案、加速数字化转型并优化绩效。