rabbitmq 注解配置使用（四）消息确认（消费）

上一个，我们总结了如何确认消息是不是到达路由和队列的方法，当然了最重要的是，我们的消费者到底接收到了这个消息没有，这个消息接收的是不是正确。一般来说为了保险起见，我们的消息一般都是需要手动确认返回的。

一种是在配置文件中

这样全局的消费者都被设置为手动返回确认消息。

或者我们也可以在单独的某个接收者中使用

来设置这个接受者类中所有的消息都是ack模式。

或者我们也可以在单独的某个接受者上用

这样都可以实现消费者进行手动确认返回，成功返回就是用channelbasicAck(deliveryTag,false);。

不成功就用basicNack。

如果开启了手动返回，但是没有返回的话，这条消息就会一直存在于队列中，每次都会重新接收。

rabbitmq接收消息怎转换成请求

作为一个，我无法确定您的具体需求，但是我可以给您提供一些基本的RabbitMQ消息处理的步骤和建议。

1 创建消息队列和交换机

在RabbitMQ中，您需要首先创建一个消息队列和一个交换机。消息队列是一种存储消息的容器，而交换机则是将消息路由到队列的组件。您可以使用RabbitMQ的管理界面或者命令行工具来创建它们。

2 定义消息格式

定义您的消息格式，这可以是任何您需要的格式，例如JSON、XML等。确保消息格式与您的应用程序兼容，并且包含所有必需的信息。

3 发送消息

在发送消息之前，您需要将消息发布到交换机中。您可以使用RabbitMQ的客户端库来完成此 *** 作。在发布消息时，您需要指定交换机的名称，消息的内容和其他必要的参数。

4 接收消息

在接收消息之前，您需要创建一个消费者来监听队列中的消息。您可以使用RabbitMQ的客户端库来创建消费者。一旦消费者被创建，它将开始监听队列中的消息并将其传递给您的应用程序。

5 处理消息

一旦您的应用程序接收到消息，它将需要进行处理。根据您的应用程序的需求，您可以将消息转换成请求，并将其发送到其他服务中。

6 返回响应

在处理请求后，您的应用程序将需要返回响应消息。您可以使用RabbitMQ的客户端库将响应消息发布到交换机中，以便其他服务可以接收并处理它。

总之，以上是一个基本的RabbitMQ消息处理流程。但是具体实现会根据您的应用程序需求而有所不同。

1生产者：创建消息，发布消息到代理服务器（RabbitMQ）

（1）消息：有效荷载和标签

（2）有效荷载：消息的内容

（3）标签：用来描述消息（交换器的名称或者可选主题的标记），然后把消息交由RabbitMQ，由RabbitMQ进行后续处理

2消费者：连接到代理服务器（RabbitMQ），并订阅到队列（queue）上，接收代理服务器发布的消息并读取

（1）接收到的消息只包括有效荷载，即消息内容

1基本原理：首先创建一条TCP连接，TCP连接打开后（即通过认证），应用程序创建一条AMQP信道。

2信道：是建立在真实的TCP连接内的虚拟连接，AMQP命令是通过信道发送出去

3应用程序和RabbitMQ代理之间的连接用信道而不直接用TCP连接的原因

（1）一个信道处理一个线程，一个TCP连接可以承载多个信道，即多个线程可以使用同一个TCP连接，减少资源消耗，避免性能瓶颈

（2）一个TCP的创建和销毁对资源的消耗会很大，创建需要三次握手，销毁需要四次挥手。

4TCP协议的三次握手和四次分手

（1）建立连接的三次握手：

-第一次握手：客户端发送给服务端，请求连接

-第二次握手：服务端接收到客户端发送的请求连接的消息，回复给客户端请求连接

-第三次握手：上述两次握手本质上已经建立连接，但是此时客户端还会发送给服务端一个消息，确认连接，即表示连接成功

（2）销毁连接的四次挥手：

-第一次挥手：客户端发送给服务端，断开连接

-第二次挥手：服务端接收到请求断开连接的请求，发送确认消息

-第三次挥手：服务端发送给客户端，断开连接

-第四次挥手：客户端接收到服务端的消息，确认断开连接

注意：销毁连接需要四次挥手是因为TCP连接是双向连接，断开也需要双向断开和确认

RabbitMQ消费者可以通过订阅给定的队列来消费消息。具体而言，消费者会向RabbitMQ服务器发送一个基于AMQP协议的请求，告诉RabbitMQ他们想要接收哪个队列中的消息。一旦有消息被推送到这个队列中，RabbitMQ就会将消息发送到所有已订阅该队列的消费者中。

在消费者接收到消息之后，它们可以使用特定的方式进行消息处理，例如将消息进行存储、转发、处理或显示给用户等。这些具体的行为取决于应用程序的设计以及与RabbitMQ通信的API的实现方式。

值得注意的是，RabbitMQ可以根据多种不同的因素来确定消息的路由和分发方式。例如，可以根据消息的类型、发送者、接收者、消息内容等信息来对消息进行分类，并将其发送到相应的队列中。消费者可以按照特定的逻辑来订阅这些队列，以接收并处理相应的消息。

在图中为 P，表示消息的发送者。

在图中为 X, 生产者发过来的消息需要经过交换机，交换机将决定将消息放到哪些队列当中。

队列在图 1 中由红色矩形阵列表示，负责保存消息和发放消息。

在图中为 C，代表等待接收消息的程序。

首先，生产者发送消息到交换机，同时发送一个 key ，通过这个 key ，交换机就知道该把消息发到哪个队列。随后交换机把消息发送到相应的队列中。由队列将消息发送给消费者。消费者监听某些队列，当有消息过来时，就立即处理消息。

fanout 交换机就跟广播一样，对消息不作选择地发给所有绑定的队列。以图 1 为例，两个队列都将收到消息。

在 direct 模式里，交换机和队列之间绑定了一个 key ，只有消息的 key 与绑定了的 key 相同时，交换机才会把消息发给该队列。如图 2 所示，消息的 key 为 orange 时，消息将进入队列 Q1 ; key 为 black 或者 green 时，消息将进入队列 Q2 。若消息的 key 是其他字符串，被交换机直接遗弃。

同时，交换机支持多重绑定，多个队列可以以相同的 key 与交换机绑定。如图 3 所示，当消息的 key 为 black 时，消息将进入 Q1 和 Q2

topic 模式可以理解为主题模式，当 key 包涵某个主题时，即可进入该主题的队列。 topic 模式的 key 必须具有固定的格式：以 作为间隔的一串单词；比如： quickorangerabbit ， key 最多不能超过 255byte 。

交换机和队列的key可以以类似正则表达式的方式存在，有两种语法：

图 4。图中， Q1 与交换机绑定的 kye 为： “orange” ，故当消息的 key 为三个单词，且中间的单词为 orange 时，消息将进入 Q1 。 Q2 与 exchange 绑定的 key 为 ”rabbit#” ，当消息的 key 以 rabbit 开头时，消息将进入 Q2 。

官网没介绍这个模式呀，大概不常用吧。

队列分发消息给消费者的方式采用循环发放。举例来说，若队列里有四个消息 w, x, y, z ，则 C1 将得到消息 z 和 x , C2 将得到消息 y 和 w 。即每个消费者按顺序每人发一个消息。

注意，在这种分配方式下，消息其实在刚进入队列的时候就已经内定好将要被分发的消费者。即 z, x 一定是给 C1 y, w 一定是给 C2 。

这种方式存在一些隐患，如果 z 和 x 都是耗时的命令、 y , z 都是简单的命令， C1 将不停地工作，而 C2 就比较空闲，造成资源浪费。

公平发放解决了上述问题。这种方式下，队列只会把消息给空闲的消费者。如果它看到某个消费者正忙，就查找下一个空闲消费者。

若没有特别设定，消息一旦被队列分发给消费者，就被 Rabbitmq 从内存中删除。

在这种情况下，如果将一个正在处理消息的消费者强行关闭，那么，消息将未被完全处理，且 RabbitMQ 完全不知情。

为了解决上述问题，可以配置使得消息处理完后，向 RabbitMQ 返回一个 Acknowledgment 。 RabbitMQ 直到收到 Acknowledgment 后，才将消息删除。

当消费者死亡时（its channel is closed, connection is closed, or TCP connection is lost）， RabbitMQ 会知道这个消费者发生问题了，将重新发送消息给空闲的消费者。

消息没有 TimeOut ，即使消费者处理很长很长时间，乃至无穷无尽， RabbmitMQ 也认为消费者正在处理。

解决方案1:

可以批量读取的。看你用客户端吧，队列有一个Prefetch count参数，就是一次读取多少条

解决方案2:

所提供接口应不支持批量，这样对于rabbitMQ所关注的可靠传递目标有所违背。

但也不用担心性能问题，记得Prefetch可以设置预读条数。

以上就是关于rabbitmq 注解配置使用（四）消息确认（消费）全部的内容，包括:rabbitmq 注解配置使用（四）消息确认（消费）、rabbitmq接收消息怎转换成请求、RabbitMQ（一）--关于消息通信等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！