RabbitMQ详细概念

在计算机科学中，消息队列（英语：Message queue）是一种进程间通信或同一进程的不同线程间的通信方式，软件的贮列用来处理一系列的输入，通常是来自用户。消息队列提供了异步的通信协议，每一个贮列中的纪录包含详细说明的数据，包含发生的时间，输入设备的种类，以及特定的输入参数，也就是说：消息的发送者和接收者不需要同时与消息队列互交。消息会保存在队列中，直到接收者取回它。

MQ的实现

消息队列常常保存在链表结构中。拥有权限的进程可以向消息队列中写入或读取消息。

目前，有很多消息队列有很多开源的实现，包括 JBoss Messaging 、 JORAM 、Apache ActiveMQ 、 Sun Open Message Queue 、 IBM MQ 、 Apache Qpid 和HTTPSQS 。

当前使用较多的消息队列有 RabbitMQ 、 RocketMQ 、 ActiveMQ 、 Kafka 、ZeroMQ 、 MetaMq 等，而部分数据库如 Redis 、 Mysql 以及 phxsql 也可实现消息队列的功能。

特点

MQ是消费者-生产者模型的一个典型的代表，一端往消息队列中不断写入消息，而另一端则可以读取或者订阅队列中的消息。

MQ和JMS类似，但不同的是JMS是SUNJAVA消息中间件服务的一个标准和API定义，而MQ则是遵循了AMQP协议的具体实现和产品。

注意：
1. AMQP ，即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。
2. JMS ，Java消息服务（Java Message Service）应用程序接口，是一个Java平台中关于面向消息中间件的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。 Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。常见的消息队列，大部分都实现了JMS API，如ActiveMQ ， Redis 以及 RabbitMQ 等。

为什么使用RabbitMQ？

AMQP，即Advanced Message Queuing Protocol，高级消息队列协议，是应用层协
议的一个开放标准，为面向消息的中间件设计。

消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。
RabbitMQ是一个开源的AMQP实现，服务器端用Erlang语言编写，支持多种客户端，如： Python 、 Ruby 、 .NET 、 Java 、 JMS 、 C 、 PHP 、 ActionScript 、XMPP 、 STOMP 等，支持AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。

总结如下：

基于AMQP协议
高并发(是一个容量的概念，服务器可以接受的最大任务数量)
高性能(是一个速度的概念，单位时间内服务器可以处理的任务数)
高可用(是一个持久的概念，单位时间内服务器可以正常工作的时间比例)
强大的社区支持，以及很多公司都在使用
支持插件
支持多语言

优缺点

优点
　　应用耦合、异步处理、流量削锋

缺点
系统可用性降低、系统复杂性增加

使用场景

消息队列，是分布式系统中重要的组件，其通用的使用场景可以简单地描述为：当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用
消息队列的时候。
在项目中，将一些无需即时返回且耗时的操作提取出来，进行了异步处理，而这种异步处理的方式大大的节省了服务器的请求响应时间，从而提高了系统的吞吐量。

三、常见MQ的对比

追求可用性：Kafka、 RocketMQ 、RabbitMQ

追求可靠性：RabbitMQ、RocketMQ

追求吞吐能力：RocketMQ、Kafka

追求消息低延迟：RabbitMQ、Kafka

四、SpringAMQP

3.1 什么是AMQP？

SpringAMQP是基于RabbitMQ封装的一套模板（API规范），并且还利用SpringBoot对其实现了自动装配，使用起来非常方便

SpringAMQP提供了三个功能：

- 自动声明队列、交换机及其绑定关系
- 基于注解的监听器模式，异步接收消息
- 封装了RabbitTemplate工具，用于发送消息

Producing 意思不仅仅是发送消息。发送消息的程序叫做producer生产者。

Queue 是一个消息盒子的名称。它存活在 RabbitMQ 里。虽然消息流经 RabbitMQ和你的应用程序，但是他们只能在 Queue 里才能被保存。Queue 没有任何边界的限制，你想存多少消息都可以，它本质上是一个无限的缓存。许多生产者都可以向一个 Queue 里发送消息，许多消费者都可以从一个 Queue 里接收消息。

Consuming 的意思和接收类似。等待接收消息的程序叫做消费者。

3.2 RabbitMQ的六种工作模式

声明队列的方式：

1、基于注解的方式

2、声明bean的方式

1、Basic Queue 简单队列模型

2、WorkQueue模式（资源竞争）

介绍：让多个消费者绑定到一个队列，共同消费队列中的消息。

注意：默认的是-消息轮询分发

问题：任务量很大，消息虽然得到了及时的消费，单位时间内消息处理速度加快，提高了吞吐量，可是不同消费者处理消息的时间不同，导致部分消费者的资源被浪费。
解决：采用消息公平分发。

总结；

Work模型的使用：

多个消费者绑定到一个队列，同一条消息只会被一个消费者处理
通过设置prefetch来控制消费者预取的消息数量

问题：生产者产生的消息只可以被一个消费者消费，可不可以被多个消费者消费呢？
解决：采用发布与订阅模式。

3、发布订阅的模型如图：

Exchange有以下3种类型：

- Fanout：广播，将消息交给所有绑定到交换机的队列
- Direct：定向，把消息交给符合指定routing key 的队列
- Topic：通配符，把消息交给符合routing pattern（路由模式）的队列

Exchange（交换机）只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与Exchange绑定，或者没有符合路由规则的队列，那么消息会丢失！

3.1 Fanout 广播（共享资源）

结果：可以看出生产者发送了一条消息，用于邮件发送和短信发送的消费者均可以收到消息进行后续处理。
问题：生产者产生的消息所有消费者都可以消费，可不可以指定某些消费者消费呢？
解决：采用direct路由模式。

3.2 Direct 定向（路由模式队列）

结果：可以看出生产者发送了多条设置了路由规则的消息，消费者可以根据具体的路由规则消费对应队列中的消息，而不是所有消费者都可以消费所有消息了。
问题：生产者产生的消息如果场景需求过多需要设置很多路由规则，可不可以减少？
解决：采用topic主题模式。

3.3 Topic 通配符（主题模式队列）

routing key 中可以存在两种特殊字符 * 与 # ，用于做模糊匹配，其中 * 用于匹配一个单词， # 用于匹配多个单词（可以是零个）

结果：可以看出生产者发送了多条设置了路由匹配规则(主题)的消息，根据不同的路由匹配规则(主题)，可以将消息根据指定的routing key路由到匹配到的队列中，也是在生产中比较常见的一种消息处理方式。
问题：RabbitMQ本身是基于异步的消息处理，是否可以同步实现？
解决：采用RPC模式。

3.4 RPC模式

MQ本身是基于异步的消息处理，但实际的应用场景中，我们很可能需要一些同步处理，需要同步等待服务端将我的消息处理完成后再进行下一步处理。这相当于RPC（Remote Procedure Call，远程过程调用）。在RabbitMQ中也支持RPC。

五、消息确认机制

4.1 事务机制

RabbitMQ中与事务机制有关的方法有三个： txSelect() , txCommit() 以及txRollback(), txSelect() 用于将当前channel设置成transaction模式，txCommit() 用于提交事务， txRollback() 用于回滚事务，在通过 txSelect()开启事务之后，我们便可以发布消息给broker代理服务器了，如果 txCommit() 提交成功了，则消息一定到达了broker了，如果在 txCommit() 执行之前broker异常崩溃或者由于其他原因抛出异常，这个时候我们便可以捕获异常通过 txRollback() 回滚事务。

4.2 confirm机制

confirm模式最大的好处在于他是异步的，一旦发布一条消息，生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息，当消息最终得到确认之后，生产者应用便可以通过回调方法来处理该确认消息，如果RabbitMQ因为自身内部错误导致消息丢失，就会发送一条nack消息，生产者应用程序同样可以在回调方法中处理该nack消息。

实现生产者confirm 机制有三种方式:
        普通confirm模式：每发送一条消息后，调用waitForConfirms()方法，等待服务器端confirm。实际上是一种串行confirm了。
        批量confirm模式：每发送一批消息后，调用waitForConfirmsOrDie()方法，等待服务器端confirm。
        异步confirm模式：提供一个回调方法，服务端confirm了一条或者多条消息后Client端会回调这个方法。

注意:两种事物控制形式不能同时开启！

Original aspirationㅤ

关注

1
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
RabbitMQ详细概念

一、初始MQ1.1 同步和异步的概念同步：好比如两个人同时打电话，需要实时响应，同步进行。异步：类似于微信发短信和收短信，一个人可以收多个人的信息，同时也可以给多个人发短信。1.2 同步和异步的优缺点1.2.1 同步同步调用的优点：时效性较强，可以立即得到结果同步调用的问题：耦合度高性能和吞吐能力下降有额外的资源消耗有级联失败问题 1.2.2 异步好处：吞吐量提升：无需等待订阅者处理完成，响应更快速
复制链接

扫一扫