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

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

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

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

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

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

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

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

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

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

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

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