消息中间件概述
文章目录
- 一 什么是消息中间件
-
- 1.1 简介
- 1.2 什么是队列
-
- 1.2.1 队列的特性
- 1.2.2 队列的分类
- 1.3 什么是消息
- 1.4 消息中间件
- 1.5 消息队列
- 1.6 消息中间件的优势
- 二 消息中间件应用场景
-
- 2.1 异步处理
- 2.2 应用解耦
- 2.3 流量削峰
- 2.4 消息驱动的系统
- 2.5 日志处理
- 2.6 顺序保证
- 2.7 消息通讯
- 三 消息中间件常用协议
-
- 3.1 JMS协议
- 3.2 AMQP协议
- 3.3 MQTT协议
- 3.4 STOMP协议
- 3.5 XMPP协议
- 3.6 其他基于TCP/IP自定义的协议
- 四 常见消息中间件的对比
-
- 4.1 RabbitMQ
-
- 简介
- 主要特性
- 优点
- 缺点
- 4.2 RocketMQ
-
- 简介
- 主要特性
- 优点
- 缺点
- 4.3 ActiveMQ
-
- 简介
- 主要特性
- 优点
- 缺点
- 4.4 Kafka
-
- 简介
- 主要特性
- 优点
- 缺点
- 4.5 总结
- 五 消息中间件的传输模式
-
- 5.1 点对点
-
- 5.1.1 即发即弃
- 5.1.2 请求/回复
- 5.2 发布/订阅模型（Pub/Sub）
一 什么是消息中间件
1.1 简介
消息中间件是基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统。
1.2 什么是队列
队列是一种线性表。它允许在表的一端插入数据，在另一端删除元素。插入元素的这一端称之为队尾。删除元素的这一端我们称之为队首。
1.2.1 队列的特性
- 在队尾插入元素，在队首删除元素
- FIFO（先进先出），就像排队取票一样
1.2.2 队列的分类
-
顺序队列
-
循环队列
1.3 什么是消息
消息是指软件对象之间进行交互作用和通讯利用的一种方式。
消息就是应用程序中间传输的数据，例如：用户下的订单、用户发表的评论、各种传感器采集的数据等等，这些都是消息，所以消息就是数据的等价名词
1.4 消息中间件
消息中间件是基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统。
消息中间件关注于数据的发送和接收，利用高效可靠的异步消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。
1.5 消息队列
消息队列是消息中间件的一种实现方式。
大部分的消息中间件都是通过消息队列这种技术来实现的，例如：ActiveMQ、RabbitMQ 、ZeroMQ、Kafka、MetaMQ、RocketMQ等。
消息队列的特点：
-
先进先出：消息队列的顺序在入队的时候就基本已经确定了，一般是不需人工干预的。
-
发布订阅：发布订阅是一种很高效的处理方式，如果不发生阻塞，基本可以当成是同步操作。
-
持久化：持久化确保消息队列的使用不只是一个部分场景的辅助工具，而是让消息队列能像数据库一样存储核心的数据。
-
分布式：在现在大流量、大数据的使用场景下，支持分布式的部署，才能被广泛使用。消息队列的定位就是一个高性能的中间件。
1.6 消息中间件的优势
系统解耦
交互系统之间没有直接的调用关系，只是通过消息传输，故系统侵入性不强，耦合度低。
提高系统响应时间
例如原来的一套逻辑，完成支付可能涉及先修改订单状态、计算会员积分、通知物流配送几个逻辑才能完成；通过MQ架构设计，就可将紧急重要（需要立刻响应）的业务放到该调用方法中，响应要求不高的使用消息队列，放到MQ队列中，供消费者处理。
为大数据处理架构提供服务
通过消息作为整合，大数据的背景下，消息队列还与实时处理架构整合，为数据处理提供性能支持。
Java消息服务——JMS
Java消息服务（Java Message Service，JMS）应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。
JMS中的P2P和Pub/Sub消息模式：点对点（point to point， queue）与发布订阅（publish/subscribe，topic）最初是由JMS定义的。这两种模式主要区别或解决的问题就是发送到队列的消息能否重复消费(多订阅)。
二 消息中间件应用场景
当你需要使用 消息队列 时，首先需要考虑它的必要性。可以使用消息队列的场景有很多，最常用的几种，是做 应用程序松耦合、异步处理模式、发布与订阅、最终一致性、错峰流控 和 日志缓冲 等。反之，如果需要 强一致性，关注业务逻辑的处理结果，则使用 RPC 显得更为合适。
2.1 异步处理
场景说明：
提供新用户注册后，发送短信或邮件的功能
传统方式：
传统的做法有有两种 1.串行方式；2.并行方式
-
串行方式
将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。
-
并行方式
将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间。
分析：
假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。
因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100）。
消息中间件方式：
引入消息队列，将不是必须的业务逻辑，将异步处理改造后的架构如下：
分析：
按照以上约定，用户的响应时间相当于是注册信息写入数据库的时间，也就是50毫秒。注册邮件，发送短信写入消息队列后，直接返回，因此写入消息队列的速度很快，基本可以忽略，因此用户的响应时间可能是50毫秒。至于从消息队列中发送邮件和短信完全可以异步处理，不受时间的限制，等邮件服务和短信服务需要的时候从消息队列中消费消息即可。
因此架构改变后，系统的吞吐量提高到每秒20 QPS。比串行提高了3倍，比并行提高了两倍。
2.2 应用解耦
场景说明：
用户下单后，订单系统需要通知库存系统。
传统方式：
传统的做法是，订单系统直接调用库存系统的接口。
传统模式的缺点：假如库存系统无法访问，则订单减库存将失败，从而导致订单失败，订单系统与库存系统耦合
消息中间件方式
消息中间件方式：
订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功
库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作
假如在下单时库存系统不能正常使用也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦
2.3 流量削峰
场景说明：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。通过加入消息队列完成如下功能：
- 可以控制活动的人数
- 可以缓解短时间内高流量压垮应用
用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。秒杀业务根据消息队列中的请求信息，再做后续处理。
2.4 消息驱动的系统
具体场景：
用户新上传了一批照片， 人脸识别系统需要对这个用户的所有照片进行聚类，聚类完成后由对账系统重新生成用户的人脸索引(加快查询)。这三个子系统间由消息队列连接起来，前一个阶段的处理结果放入队列中，后一个阶段从队列中获取消息继续处理。
该方法有如下优点：
- 避免了直接调用下一个系统导致当前系统失败；
- 每个子系统对于消息的处理方式可以更为灵活，可以选择收到消息时就处理，可以选择定时处理，也可以划分时间段按不同处理速度处理；
2.5 日志处理
将消息队列用在 日志处理 中，比如 Kafka 的应用，解决 海量日志 传输和缓冲的问题。
应用案例：
把日志进行集中收集，用于计算 PV、用户行为分析 等等。
此时需要一个集中化的日志管理系统，现在比较流行的方案是ELK（elasticsearch、logstash、kibana）+ Kafka的方案
2.6 顺序保证
在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。
2.7 消息通讯
消息队列一般都内置了 高效的通信机制，因此也可以用于单纯的 消息通讯，比如实现 点对点消息队列 或者 聊天室 等。
三 消息中间件常用协议
3.1 JMS协议
JMS即Java消息服务（Java message service）应用程序接口，是一个Java平台中关于面向消息中间件（MOM）的API，用于两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。
优点：异步、可靠
3.2 AMQP协议
AMQP即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。
优点：可靠、通用
3.3 MQTT协议
MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。
优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统
3.4 STOMP协议
STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。
优点：命令模式（非topic\queue模式）
3.5 XMPP协议
XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。
优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大
3.6 其他基于TCP/IP自定义的协议
有些特殊框架（如：redis、kafka、zeroMq等）根据自身需要未严格遵循MQ规范，而是基于TCP\IP自行封装了一套协议，通过网络socket接口进行传输，实现了MQ的功能。
四 常见消息中间件的对比
当前使用较多的消息队列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMQ等，而部分数据库如Redis、MySQL以及phxsql也可实现消息队列的功能。
4.1 RabbitMQ
简介
RabbitMQ于2007年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。
RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。
主要特性
- 可靠性：提供了多种技术可以让你在性能和可靠性之间进行权衡。这些技术包括持久性机制、投递确认、发布者证实和高可用性机制；
- 灵活的路由：消息在到达队列前是通过交换机进行路由的。RabbitMQ为典型的路由逻辑提供了多种内置交换机类型。如果你有更复杂的路由需求，可以将这些交换机组合起来使用，你甚至可以实现自己的交换机类型，并且当做RabbitMQ的插件来使用；
- 消息集群：在相同局域网中的多个RabbitMQ服务器可以聚合在一起，作为一个独立的逻辑代理来使用；
- 队列高可用：队列可以在集群中的机器上进行镜像，以确保在硬件问题下还保证消息安全；
- 支持多种协议：支持多种消息队列协议；
- 支持多种语言：用Erlang语言编写，支持只要是你能想到的几乎所有编程语言；
- 管理界面：RabbitMQ有一个易用的用户界面，使得用户可以监控和管理消息Broker的许多方面；
- 跟踪机制：如果消息异常，RabbitMQ 提供消息跟踪机制，使用者可以找出发生了什么；
- 插件机制：提供了许多插件，来从多方面进行扩展，也可以编写自己的插件。
优点
- 由于Erlang语言的特性，消息队列性能较好，支持高并发；
- 健壮、稳定、易用、跨平台、支持多种语言、文档齐全；
- 有消息确认机制和持久化机制，可靠性高；
- 高度可定制的路由；
- 管理界面较丰富，在互联网公司也有较大规模的应用，社区活跃度高。
缺点
- 尽管结合 Erlang 语言本身的并发优势，性能较好，但是不利于做二次开发和维护；
- 实现了代理架构，意味着消息在发送到客户端之前可以在中央节点上排队。此特性使得RabbitMQ易于使用和部署，但是使得其运行速度较慢，因为中央节点 增加了延迟，消息封装后也比较大；需要学习比较复杂的接口和协议，学习和维护成本较高。
4.2 RocketMQ
简介
阿里系下开源的一款分布式、队列模型的消息中间件，原名Metaq，3.0版本名称改为RocketMQ，是阿里参照kafka设计思想使用java实现的一套mq。同时将阿里系内部多款mq产品（Notify、metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构，在阿里内部被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。
支持的客户端语言不多，目前是Java及C++，其中C++还不成熟；
主要特性
- 基于 队列模型：具有高性能、高可靠、高实时、分布式等特点；
- Producer、Consumer、队列都支持分布式；
- Producer向一些队列轮流发送消息，队列集合称为Topic。Consumer如果做广播消费，则一个Consumer实例消费这个Topic对应的所有队列；如果做集群消费，则多个Consumer 实例平均消费这个Topic对应的队列集合；
- 能够保证严格的消息顺序；
- 提供丰富的消息拉取模式；
- 高效的订阅者水平扩展能力；
- 实时的消息订阅机制；
- 亿级消息堆积 能力；
- 较少的外部依赖。
优点
- 单机支持1万以上持久化队列；
- RocketMQ的所有消息都是持久化的，先写入系统PAGECACHE，然后刷盘，可以保证内存与磁盘都有一份数据，而访问时，直接从内存读取。
- 模型简单，接口易用（JMS的接口很多场合并不太实用）；
- 性能非常好，可以允许大量堆积消息在Broker中；
- 支持多种消费模式，包括集群消费、广播消费等；
- 各个环节分布式扩展设计，支持主从和高可用；
- 开发度较活跃，版本更新很快。
缺点
- 支持的 客户端语言不多，目前是Java及C++，其中C++还不成熟；
- RocketMQ社区关注度及成熟度也不及前两者；
- 没有Web管理界面，提供了一个 CLI (命令行界面) 管理工具带来查询、管理和诊断各种问题；
- 没有在MQ核心里实现JMS等接口；
4.3 ActiveMQ
简介
ActiveMQ是由Apache出品，ActiveMQ是一个完全支持JMS1.1和J2EE 1.4规范的JMS Provider实现。它非常快速，支持多种语言的客户端和协议，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能。
主要特性
- 服从JMS规范：JMS 规范提供了良好的标准和保证，包括：同步 或 异步 的消息分发，一次和仅一次的消息分发，消息接收和订阅等等。遵从JMS规范的好处在于，不论使用什么JMS实现提供者，这些基础特性都是可用的；
- 连接灵活性：ActiveMQ提供了广泛的连接协议，支持的协议有：HTTP/S，IP多播，SSL，TCP，UDP等等。对众多协议的支持让ActiveMQ拥有了很好的灵活性；
- 支持的协议种类多：OpenWire、STOMP、REST、XMPP、AMQP；
- 持久化插件和安全插件：ActiveMQ提供了多种持久化选择。而且，ActiveMQ的安全性也可以完全依据用户需求进行自定义鉴权和授权；
- 支持的客户端语言种类多：除了Java之外，还有：C/C++，.NET，Perl，PHP，Python，Ruby；
- 代理集群：多个ActiveMQ代理可以组成一个集群来提供服务；
- 异常简单的管理：ActiveMQ是以开发者思维被设计的。所以，它并不需要专门的管理员，因为它提供了简单又使用的管理特性。有很多中方法可以监控ActiveMQ不同层面的数据，包括使用在JConsole或者在ActiveMQ的WebConsole中使用JMX。通过处理JMX的告警消息，通过使用命令行脚本，甚至可以通过监控各种类型的日志。
优点
- 跨平台(JAVA编写与平台无关，ActiveMQ几乎可以运行在任何的JVM上)；
- 可以用JDBC：可以将数据持久化到数据库。虽然使用JDBC会降低ActiveMQ的性能，但是数据库一直都是开发人员最熟悉的存储介质；
- 支持JMS规范：支持JMS规范提供的统一接口;
- 支持自动重连和错误重试机制；
- 有安全机制：支持基于shiro，jaas等多种安全配置机制，可以对Queue/Topic进行认证和授权；
- 监控完善：拥有完善的监控，包括WebConsole，JMX，Shell命令行，Jolokia的RESTful API；
- 界面友善：提供的WebConsole可以满足大部分情况，还有很多第三方的组件可以使用，比如hawtio；
缺点
- 社区活跃度不及RabbitMQ高；
- 根据其他用户反馈，会出莫名其妙的问题，会丢失消息；
- 目前重心放到activemq6.0产品Apollo，对5.x的维护较少；
- 不适合用于上千个队列的应用场景；
4.4 Kafka
简介
Apache Kafka是LinkedIn开源的分布式发布-订阅消息系统（使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统）。它最初由LinkedIn公司基于独特的设计实现为一个分布式的日志提交系统(a distributed commit log)，之后成为Apache项目的一部分，目前归属于Apache顶级项目。
Kafka主要为高吞吐量的订阅发布系统而设计，追求速度与持久化。kafka中的消息由键、值、时间戳组成，kafka不记录每个消息被谁使用，只通过偏移量记录哪些消息是未读的，kafka中可以指定消费组来实现订阅发布的功能。
主要特性
- 快速持久化：可以在O(1)的系统开销下进行消息持久化；
- 高吞吐：在一台普通的服务器上既可以达到10W/s的吞吐速率；
- 高堆积：支持topic下消费者较长时间离线，消息堆积量大；
- 完全的分布式系统：Broker、Producer和Consumer都原生自动支持分布式，自动实现负载均衡；
- 支持同步和异步复制两种高可用机制；
- 支持数据批量发送和拉取；
- 零拷贝技术(zero-copy)：减少IO操作步骤，提高系统吞吐量；
- 数据迁移、扩容对用户透明；
- 无需停机即可扩展机器；
- 支持Hadoop数据并行加载：对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。
- 其他特性：丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力、定期删除机制；
优点
- 客户端语言丰富：支持Java、.Net、PHP、Ruby、Python、Go等多种语言；
- 高性能：单机写入TPS约在100万条/秒，消息大小10个字节；
- 提供完全分布式架构，并有replica机制，拥有较高的可用性和可靠性，理论上支持消息无限堆积；
- 支持批量操作；
- 消费者采用Pull方式获取消息。消息有序，通过控制能够保证所有消息被消费且仅被消费一次；
- 有优秀的第三方KafkaWeb管理界面Kafka-Manager；
- 在日志领域比较成熟，被多家公司和多个开源项目使用。
缺点
- Kafka单机超过64个队列/分区时，Load时会发生明显的飙高现象。队列越多，负载越高，发送消息响应时间变长；
- 使用短轮询方式，实时性取决于轮询间隔时间；
- 消费失败不支持重试；
- 支持消息顺序，但是一台代理宕机后，就会产生消息乱序；
- 社区更新较慢。
4.5 总结
| RabbitMQ | RocketMQ | ActiveMQ | Kafka | |
|---|---|---|---|---|
| 设计定位 | 可靠消息传输 | 非日志的可靠消息传输 | 可靠消息传输 | 实时数据处理及日志处理 |
| 所属社区/公司 | Apache | Alibaba开发，现已加入Apache | Apache | Apache |
| 成熟度 | 成熟 | 成熟 | 成熟 | 日志领域成熟 |
| 社区活跃度 | 高 | 中 | 高 | 高 |
| API完备性 | 高 | 高 | 高 | 高 |
| 开发语言 | ErLang | Java | Java | Scala |
| 持久化方式 | 内存、文件 | 磁盘文件 | 内存、文件、数据库 | 磁盘文件 |
| 客户端支持语言 | Python Java Ruby PHP C# JavaScript Go Elixir Objective-C Swift |
Java、C++（不成熟） | C C++ C# Delphi Erlang Adobe Flash Haskell Java JavaScript Perl PHP Pike Pytho Ruby |
C C++ Erlang Java .net per PHP Python Ryby Go JavaScript |
| 部署方式 | 单机/集群 | 单机/集群 | 单机/集群 | 单机/集群 |
| 集群管理方式 | 独立 | nameserver | 独立 | zookeeper |
| 可用性 | 高，基于主从架构实现高可用 | 非常高，分布式架构 | 高，基于主从架构实现高可用 | 非常高，分布式。一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
| 消息写入性能 | 较好 | 很好 | 较好 | 非常好 |
| 单机队列数 | 依赖内存 | 单机最高5万 | 较好 | 单机超过64个队列或分区时负载变高 |
| 单机吞吐量 | 万级，比 RocketMQ、Kafka 低一个数量级 | 10 万级，高吞吐 | 万级，比 RocketMQ、Kafka 低一个数量级 | 10 万级，高吞吐 |
| 时效性 | 微秒级，这是 RabbitMQ 的一大特点，延迟最低 | ms 级 | ms 级 | 延迟在 ms 级以内 |
| 事务消息 | 不支持 | 支持 | 支持 | 不支持 |
| 消息过滤 | 不支持 | 支持 | 不支持 | 不支持 |
| 消息失败重试 | 支持 | 支持 | 支持 | 不支持 |
| 消息重新消费(消息幂等性问题) | 不支持 | 支持 | 支持 | 支持 |
| 批量发送 | 不支持 | 支持 | 支持 | 支持 |
| 消息清理 | 可用内存少于40%触发gc | 指定文件保存时间过期删除 | 指定文件保存时间过期删除 | 指定文件保存时间过期删除 |
结论：
- Kafka 在于 分布式架构，RabbitMQ 基于 AMQP 协议 来实现，RocketMQ 的思路来源于 Kafka，改成了 主从结构，在 事务性 和 可靠性 方面做了优化。广泛来说，电商、金融 等对 事务一致性 要求很高的，可以考虑 RabbitMQ 和 RocketMQ，对 性能要求高 的可考虑 Kafka。
- 按照目前网络上的资料，RabbitMQ、activeMQ、zeroMQ三者中，综合来看，RabbitMQ是首选，但是activeMQ与Java结合度比较好。
五 消息中间件的传输模式
消息中间件的传输模式是指消息的发送和接受模式，大致分为两种：
- 点对点模式
- 发布订阅模式
5.1 点对点
点对点模型 用于 消息发送者 和 消息接收者 之间 点到点 的通信。消息发送者将消息发送到由某个名字标识的特定接收者。这个名字实际上对于消费服务中的一个 队列（Queue），在消息传递给接收者之前它被 存储 在这个队列中。队列消息 可以放在 内存 中也可以 持久化，以保证在消息服务出现故障时仍然能够传递消息。
传统的点对点消息中间件通常由 消息队列服务、消息传递服务、消息队列 和 消息应用程序接口 API 组成，其典型的结构如下图所示：
特点：
- 每个消息只用一个接收者；
- 发送者和接收者没有时间依赖；
- 接收者确认消息接收和处理成功。
在点对点模型中，即使许多消息接收者在同一个消息队列中侦听，但是消息从消息发送者发送到只有一个接收者。
在点对点模式中又有两种类型的点对点消息传递：
- 即发即弃（单向）
- 消息传递和请求/回复（请求-响应）消息传递
5.1.1 即发即弃
在即发即弃中，消息发送方不会等待来自消息队列的任何响应。它不关心消息队列是否接收到消息，在这个模式中，消息发送者和接收者根本没有交互。
5.1.2 请求/回复
与即发即弃模式不同，在请求/回复消息模式中，消息发送方在队列上发送一条消息，然后等待接收方的响应。使用这种模式，发送关心它是否收到或未收到的消息状态。
5.2 发布/订阅模型（Pub/Sub）
发布者/订阅者 模型消息传递或通常称为发布/订阅消息传递时一种异步形式。
发布者/订阅者 模型支持向一个特定的 消息主题 生产消息。0 或 多个订阅者 可能对接收来自 特定消息主题 的消息感兴趣。
在这种模型下，发布者和订阅者彼此不知道对方，就好比是匿名公告板。这种模式被概况为：多个消费者可以获得消息，在 发布者 和 订阅者 之间存在 时间依赖性。发布者需要建立一个 订阅（subscription），以便能够消费者订阅。订阅者 必须保持 持续的活动状态 并 接收消息。在这种情况下，在订阅者 未连接时，发布的消息将在订阅者 重新连接 时 重新发布。
点对点和发布/订阅消息模型之间的区别在于消息接收者数量。另一个区别是在点对点模型中，消息发送者必须知道接收方，但在发布/订阅中，消息发布者不需要知道消息将在哪里消费。该特性在应用 发布/订阅消息模型时为应用程序提供了高度解耦。
特性：
- 每个消息可以有多个订阅者；
- 客户端只有订阅后才能接收到消息；
- 持久订阅和非持久订阅。
注意：
- 发布者和订阅者有时间依赖：接受者和发布者只有建立订阅关系才能收到消息；
- 持久订阅：订阅关系建立后，消息就不会消失，不管订阅者是否都在线；
- 非持久订阅：订阅者为了接受消息，必须一直在线。当只有一个订阅者时约等于点对点模式