消息队列：简介

什么是消息队列？

消息队列是消息传递中间件解决方案的一个组件，旨在支持独立的应用和服务之间的信息交换。消息队列按发送顺序存储“消息”（由应用所创建、供其他应用使用的数据包），直到使用方应用能够处理它们为止。这些消息安全地等待接收方应用做好准备，因此，即使网络或接收方应用出现问题，消息队列中的消息也不会丢失。

这种称为异步消息传递的模式可防止数据丢失，并使系统能够在流程或连接失败时继续工作。这也使开发人员能够将流程与应用分离，确保它们的通信是独立的，而且由事件驱动，从而使架构更加可靠。

消息队列可用于众多部署选项中的消息传递解决方案，包括经过优化的实体设备、云服务、大型机以及软件。

优点

消息队列解决方案广泛应用于各行各业，为开发人员和系统管理员带来一系列优点，包括：

可靠的消息交付：使用消息队列可以确保应用之间的业务关键型消息不会丢失，并且只会传递给接收方一次。这种功能消除了对额外的数据去重或防丢失逻辑的需求。
应用间连接：一些消息队列解决方案可以处理应用和服务之间的消息加密、事务性和其他通信任务。这简化了应用开发，使不同的架构能够协同工作。
多功能性：消息队列解决方案可以支持多种语言，如 Java、Node.js、COBOL、C/C++、Go、.NET、Python、Ruby 和 C#。它们还支持多种应用编程接口 (API) 和协议，包括 MQTT、AMQP 及 REST 等。
弹性：异步消息传递可确保特定于应用的故障不会影响到系统。当系统中的一个组件停止工作时，所有其他组件都可以继续与队列交互并处理消息。这降低了由于某一部分的故障而影响到整个系统稳定性的机会。
更高的安全性：有些消息队列可识别和验证所有消息，另一些则能够对静止存储、传输中或端到端的消息进行加密。这有助于提高应用和/或基础架构的整体安全性。
集成式文件传输：一些消息队列解决方案包含额外的功能，如传输文件能力。因此可用于取代企业中使用的 FTP。

用例

当今的企业计算环境非常复杂，而且高度分散。消息传递提供强大、安全的单一共享式消息传递主干，能够更轻松地集成各种不同平台上的应用和服务。这可以防止数据丢失，甚至能够确保系统在连接不稳定的情况下继续正常工作。

消息队列特别适合于将本地后端系统与云服务集成。在云架构中，应用通常分解成独立的小组件。这样应用的设计和编码工作就更加轻松，性能管理也更方便。消息队列使这些解耦的基于云的应用能够彼此通信或与本地系统通信。

由于消息队列中的消息可持久保存，因此增强了架构弹性。这意味着消息会存储到磁盘，直到接收消息的服务确认可以处理它们为止。消息传递队列可用于需要高级别安全性、容错性和准确性的场景，例如金融交易处理、机票预订或患者病历更新等。

消息队列还可用于支持位于不同云（无论是公有云还是私有云）中的应用和系统进行通信，即使它们位于不同的国家或地区甚至不同的大陆也不例外。使用消息队列可以提高容错性，并可用于防止数据在地理位置和技术上完全不同的系统之间出现重复或丢失问题。由于系统中的每个服务都是解耦的，或者说在逻辑上与其他服务分离，因此，无论哪个服务或应用出现故障或停止工作，其他服务都可以继续正常运行。

消息队列可用于各种不同的应用，如移动应用、物联网应用和传统的事务系统记录。它们还支持各种平台 — 如虚拟机和容器，并支持原有应用和当前最新解决方案之间的集成。

消息队列与其他机制之比较

消息队列与发布/订阅
消息队列使用点到点消息传递模式，一个应用（称为发送方）向队列提交消息，另一个应用（称为接收方）从队列中获取并使用消息。发送方和使用方之间建立紧密耦合的一对一关系，每条消息只会使用一次。

如果应用需要将消息分发给多个接收方，可选择组合多个消息队列，也可以使用发布/订阅消息传递模式。

在发布/订阅消息传递中，生成消息的应用称为发布方，使用消息的应用称为订阅方。每条消息都发布到一个主题，订阅该主题的每个应用都会获得发布到该主题的所有消息的副本。

大多数的消息传递中间件解决方案都同时支持消息队列（点对点）和发布/订阅消息传递模式。

消息队列与消息总线
消息传递总线是企业服务总线 (ESB) 的一种类型，支持服务随时随地访问数据，同时确保它们在分布式系统架构中保持解耦和独立运行。使用消息总线时，所有的服务或应用必须共享相同的数据类型、命令集和通信协议，尽管它们可能是使用不同语言编写的。使用方可以决定他们如何使用消息。

如果解耦的应用希望通过消息总线进行通信，则必须对消息进行转换，确保它们具有相同类型的消息。而消息队列则传输消息，无论它们是相同类型还是不同类型。

消息队列与 web 服务
应用可通过web 服务（即基于标准协议（如简单对象访问协议 (SOAP) 或 HTTP）的 API）直接通信，而不是通过消息传递中间件进行通信。 Web 服务广泛应用于分布式系统，相对简单而且易于实施，这使得它们在某些用例和场景中成为消息队列的可行替代方案。

但是，与消息队列不同，web 服务不能保证消息送达。如果服务器或连接发生故障，您必须能够在客户端处理错误。 Web 服务还缺少“发布/订阅”分发模式。消息传递中间件提供了更出色的容错性和更好的功能，用于处理繁忙的流量或活动激增情况。

如欲详细了解何时使用 API、何时使用消息传递或何时将二者结合使用，请参阅"API 和消息传递简介。"

消息队列与数据库
在某些情况下，数据库可用作消息队列的替代方案，但在大多数情况下，它们用于不同的目的，并且不能轻易互换。数据库最常用于存储目的，使用户能够一而再地访问相同的信息。消息队列则无法用于存储目的。消息一经使用，就会从队列中删除。

可以在数据库中设计类似消息队列的功能，但这需要大量的编码工作和丰富的知识。数据库只能用于复制简单的队列结构，无法通过扩展以支持更大的应用。

请参阅“数据库格局概述”，了解有关数据库及其功能的更多信息。

消息队列即服务

消息队列传统上是由 IT 部门的专门团队负责管理的。但是，通过使用“即服务”式交付，也就是使用云托管的消息队列，个人或业务部门 (LOB) 用户可通过门户网站，请求由自己更改消息传递基础架构，从而提高了敏捷性。

消息队列即服务自然而然地适用于云原生开发环境中常见的无服务器或微服务架构。因为它是以云托管服务模式提供的，因此，云提供商负责处理消息传递基础架构的所有置备、安装和维护任务，并将它托管在云中。

教程

如果您对开发使用 IBM MQ 进行通信的应用还不熟悉，那么，以下教程会有所帮助：

以下额外的资源提供更全面的信息：