01 消息队列介绍

目录

01 消息队列

Pt1 什么是MQ？

Pt2 为什么用MQ？

Pt3 AMQP协议

Pt3.1 AMQP发展史

Pt3.2 AMQP协议

---

01 消息队列

Pt1 什么是MQ？

MQ（消息队列），是一种跨进程的通信服务，用于上下游系统传递消息。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程通信，进行分布式系统的集成。

MQ具有以下特点：

1. 独立运行的服务。生产者和消费者都需要和MQ服务建立连接才能通信。

2. 采用队列的数据结构，具有FIFO特性。

3. 具有发布订阅模型。

---

Pt2 为什么用MQ？

服务通信有很多种方式，尤其是在微服务大行其道的年代，基于HTTP、TCP、RPC、SpringCloud、ServiceMesh等协议（或者服务架构）的通信模式非常之多，相比之下MQ有什么特性呢？

(1) 实现异步通信

这是很多同步协议或者框架做不到的，客户端线程不用一直等待服务端的响应才能执行下一步操作，用户也不用看着loading图片一直转圈来等待后端服务的支付结果响应。异步通信提升客户端并发性能，提高用户体验。

(2) 实现系统解耦

尤其是在分布式环境中，微服务架构下，服务调用链路长、节点多，MQ能够有效的解决多系统耦合性问题，提升系统的可扩展性和可维护性。

(3) 实现流量消峰

对于高并发的服务，流量高峰时往往会导致服务端大量请求线程等待执行，极端情况下压崩服务端节点。为了有效保护服务端稳定可靠，在入口出将流量承接下来然后转发到MQ中，再通过消费MQ消息来执行核心逻辑，这样入口处只有发送MQ而没有大量的业务逻辑，TPS非常高，能顶住洪峰流量的压力。

还有种情况就是，在服务中由两部分业务逻辑，一部分执行效率非常高，实时性要求也非常高，另一部分执行效率低，实时性要求也不是很高，为了将服务TPS发挥到最大，利用MQ将耗时高的部分逻辑异步化，从而提升服务整体TPS。最常见的就是数据库异步写。

流量消峰在电商抢购、双十一、618、过年红包时经常被应用。

(4) 实现广播通信

MQ可以实现一对多通信，这是MQ自带的能力，也是很多点对点服务模式做不到的。

比如，一笔订单交易完成后，需要将支付状态通知路由系统、风控系统、数据中心，使用MQ可以简单高效的实现。

---

Pt3 AMQP协议

Pt3.1 AMQP发展史

消息队列（Message Queue）起源于一位来自 MIT 的硬件设计教育工作者 Vivek Ranadivé设想了一种通用软件总线，就像主板上的总线那样，供其他应用程序接入。

Vivek在1983年成立了Teknekron，高盛等公司作为第一批用户再金融交易中采用了 Teknekron的软件，同时还诞生了第一代消息队列软件：Teknekron的The Information Bus（TIB）。

Teknekron的TIB允许应用开发者建立一系列规则去描述消息内容，只要消息按照这些规则发布出去，任何消费者应用都可以订阅感兴趣的内容，信息的生产者和消费者完全解耦，并且可以再传输过程中灵活混合。这个特性引起了电信特别是新闻机构的注意。1994年路透社收购了Teknekron。

由于消息队列再金融交易中应用的反响，IBM在1990年也开始研发自己的消息队列软件（IBM MQ），并且逐步演化成 WebSphere MQ 并统治着商业消息队列平台市场。同时微软开发了Microsoft Message Queue（MSMQ）。然而这些商业MQ问题存在供应商壁垒，各个厂商的 MQ 之间无法互通。

为了解决这个问题，Java Message Service（JMS）在2001年诞生了，试图通过提供公共JavaAPI的方式隐藏MQ各个供应商提供的实际接口，从而跨越壁垒和解决互通问题，但是由于使用单独的标准化接口来胶合众多不同的接口使应用程序反而变得更加脆弱。

2004年JPMorgan Chase和iMatix公司一起合作开发Advanced Message Queuing Protocol（AMQP，高级消息队列协议），从一开始就设计成为开放标准，任何人都可以执行这一标准，针对该标准任何人都可以和任何 AMQP 供应商提供的 MQ 服务器进行交互。

Pt3.2 AMQP协议

AMQP，即Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件同产品，不同的开发语言等条件的限制。

AMQP协议这种降低耦合的机制是基于与上层产品，语言无关的协议。是一种二进制协议，提供客户端应用与消息中间件之间多通道、协商、异步、安全、中立和高效地交互。

从整体来看，AMQP协议可划分为两层：

• Functional Layer 功能层，位于协议上层主要定义了一组命令（基于功能的逻辑分类），用于应用程序调用实现自身所需的业务逻辑。例如：应用程序可以通过功能层定义队列名称，生产消息到指定队列，消费指定队列消息等基于Message queues 模型。

• Transport Layer 传输层，基于二进制数据流传输，用于将应用程序调用的指令传回服务器，并返回结果，同时可以处理信道复用，帧处理，内容编码，心跳传输，数据传输和异常处理。 传输层可以被任意传输替换，只要不改变应用可见的功能层相关协议，也可以使用相同的传输层，同时使用不同的高级协议。

AMQ 模型设计驱动基于如下要求：

1. 保证基于模型实现的应用之间相互可以联通；

2. 提供对服务质量的可靠控制；

3. 命名规划，要求命名明确且保持一致；

4. 允许通过协议配置服务器连接；

5. 功能层命名能够简单的映射到应用程序级别的 API；

6. 职责单一明确，每个操作只做一件事情。

AMQP 传输层设计驱动基于如下要求：

1. 使用二进制数据流压缩和解压，提高效率；

2. 可以处理任意大小的消息，且不做任何限制；

3. 单个连接支持多个通信通道；

4. 客户端和服务端基于长链接实现，且无特殊限制；

5. 允许异步指令基于管道通信；

6. 易扩展，基于新的需求和变化支持扩展；

7. 新版本向下兼容老版本；

8. 基于断言模型，异常可以快速定位修复；

9. 对编程语言保持中立；

10. 适应代码发展演变；

关于AMQP模型的组件和流程，因为RabbitMQ是基于AMQP模型实现，在RabbitMQ部分会详细介绍，这里就不细说。