MQ回顾之rabbitmq速通

最新推荐文章于 2024-11-04 21:42:42 发布

明天一定.

最新推荐文章于 2024-11-04 21:42:42 发布

阅读量1.2k

点赞数 11

分类专栏： mq 文章标签： java-rabbitmq rabbitmq java

本文链接：https://blog.csdn.net/wai_58934/article/details/135845049

版权

mq 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

rabbitMQ相对来说功能比较完善，吞吐量会低一点。

持续更新……

安装

docker

测试选择docker安装

官方安装操作

1、docker pull rabbitmq:latest

2、docker run -d --hostname my-rabbit --name some-rabbit -p 15672:15672 -p 5672:5672 rabbitmq

3、docker exec -it 容器id /bin/bash

3.1、rabbitmq-plugins enable rabbitmq_management

消费者确认机制ack

如果一个消费者在没有发送ack的情况下死亡(它的信道被关闭、连接被关闭或TCP连接丢失)，RabbitMQ会认为消息没有被完全处理，并将其重新排队。如果同时有其他消费者在线，它会很快将其重新交付给另一个消费者。

关键代码案例-消费

// 一次只接受一个未被ack的消息
channel.basicQos(1);

// 手动ack
channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);

// 设置不自动ack
boolean autoAck = false;
channel.basicConsume(QUEUE_NAME, autoAck, deliverCallback, consumerTag -> { });

消费者未ack时将会被阻塞，在消费者交付确认时强制执行超时(默认为30分钟)。这有助于检测那些从不承认交付的有问题(卡住)的消费者。

生产者确认机制confirms和事务

生产者将信道设置成confirm模式，所有在该信道上面发布的消息都会被指派一个唯一的ID(从1开始)，一旦消息被投递到所有匹配的队列之后，broker就会发送一个确认给生产者（包含消息的唯一ID）。confirm模式最大的好处在于他是异步的，生产者可以在等信道返回确认的同时继续发送下一条消息。

同步确认：publisher-confirm-type: simple

异步确认：publisher-confirm-type: correlated

RabbitMQ中与事务机制有关的方法有三个：txSelect(), txCommit()以及txRollback(), txSelect用于将当前channel设置成transaction模式，txCommit用于提交事务，txRollback用于回滚事务。

消息持久化

关键代码案例-发布

boolean durable = true;
channel.queueDeclare("hello", durable, false, false, null);

// 标记持久消息

channel.basicPublish("", "task_queue",
            MessageProperties.PERSISTENT_TEXT_PLAIN,
            message.getBytes());

需要注意的是：RabbitMQ不允许你用不同的参数重新定义一个已经存在的队列，任何尝试这样做的程序都会返回错误。

任务分配

在不配置情况下它不会查看消费者的未确认消息数量。它只是盲目地将第n条消息分发给第n个消费者。它会均匀地分发消息，而不考虑消费者的消费能力。

为了克服这个问题，我们可以使用prefetchCount = 1的basicQos方法。这告诉RabbitMQ不要一次给worker发送多条消息。换句话说，在worker处理并确认前一条消息之前，不要将新消息分发给worker。相反，它会将其分发给下一个不忙的worker。防止消费能力差/任务重的消费者堆积。

关键代码案例-消费

// 一次只接受一个未被ack的消息
channel.basicQos(1);

Exchanges交换器

RabbitMQ消息模型的核心思想是生产者从不直接将任何消息发送到队列。实际上，很多情况下，生产者根本不知道消息是否会被传递到任何队列。

生产者只能向exchange发送消息(通常情况下，也可以直接向队列发消息，不推荐)，exchange必须确切地知道如何处理接收到的消息。这些规则由exchange类型定义。

交换类型分为:direct、topic、headers和fanout

fanout：它将接收到的所有消息广播给它知道的所有队列。
direct：消息将发送到绑定键与消息的路由键完全匹配的队列。
topic：路由键是由点分隔的单词，不超过255 bytes。特殊符号*表示替代一个词；特殊符号#表示替代零个或多个词。
headers：设置key和value的规则和queue绑定，需要设置验证消息的header。性能差，一般不用。

临时队列

队列用完即删。

服务器为我们选择一个随机的队列名称。一旦我们断开了消费者的连接，队列被自动删除。

String queueName = channel.queueDeclare().getQueue();

Bindings绑定

交换器和队列之间的关系称为绑定(binding)。

模板

channel.queueBind(queueName, exchangesName, "");

从${exchangesName}里来的消息将会发往${queueName}

参数routingKey

上边模板可以看出来bind还有第三个参数，这个参数是routingKey。如果交换类型是fanout则会忽略此值。可以使用direct模式

需要注意的是使用同一个绑定键绑定多个队列是完全可以的。

模拟实现RPC

常用消息属性

deliveryMode：将消息标记为持久的(值为2)或临时的(任何其他值)

contentType：用于描述编码的mime-type。

replyTo：通常用于命名回调队列

correlationId：用于将RPC响应与请求关联起来

总览

生产者向request-queue发送消息并且为每个消息创建单独的reply-queue供消费者发送响应，生产者通过CompletableFuture阻塞获取响应。

消费者消费request-queue消息并且拿到消息中的reply-queue-name，向其发送调用响应。

官方代码案例：RPCClient.java and RPCServer.java.

死信队列

死信队列需要配置和队列的关联。

来自队列的消息可能是死信(dead-lettered)意味着当以下事件发生时，消会息重新发布到交换器。

消息通过被消费者使用basic.reject或者basic.nack以及requeue参数设置为false去否定
消息生存时间过期。
因为队列限制，消息被丢弃。

注意：如果是队列过期，则不会使消息变为死信。

如果没配置死信队列出现以上情况，消息则会被丢弃

消息TTL和队列TTL

可以和死信队列配合用作设计超时订单，延时消息。

消息TTL决定消息在队列中可以保留多长时间。如果消息在队列中的保留时间超过了该消息的TTL，则该消息将过期而被丢弃。

懒惰队列

定义：队列中的消息实际上尽可能早地移动到磁盘。这些消息只有在使用者请求时才加载到内存中。

使用场景：消费能力差，队列消息太多，内存不足导致队列进程阻塞。

优先级队列

队列优先级是0~255可选的一个整数，不建议设置太大，原因是：每个队列的每个优先级都有一些内存和磁盘开销。这还会产生额外的CPU成本。强烈建议在1~5之间。

批量发送消息

rabbitMQ批量发送的消息和其他mq不同，在broker存储的是一条聚合消息。另外，BatchingRabbitTemplate 提供的批量发送消息的能力比较弱。对于同一个 BatchingRabbitTemplate 对象来说，同一时刻只能有一个批次(保证 Exchange + RoutingKey 相同)，否则会报错。

spring中消费异常处理

在执行顺序上，RabbitListenerErrorHandler 先于 ErrorHandler 执行。不过这个需要建立在一个前提上，RabbitListenerErrorHandler 需要继续抛出异常。

另外，RabbitListenerErrorHandler 需要每个 @RabbitListener 注解上，需要每个手动设置下 errorHandler 属性。而 ErrorHandler 是相对全局的，所有 SimpleRabbitListenerContainerFactory 创建的 SimpleMessageListenerContainer 都会生效。