1.RabbitMQ

已于 2023-08-18 10:05:48 修改
阅读量119 收藏
点赞数
分类专栏： java中间件 文章标签： 中间件 java redis rabbitmq
于 2023-07-12 19:41:51 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43456806/article/details/131688983
版权
本文介绍了JMS规范中的关键字段，如目的地、投递模式和消息类型，并详细解析了RabbitMQ的架构、工作原理和命令行工具。此外，还对比了RabbitMQ、RocketMQ和Kafka这三种消息中间件的优缺点，以及如何在RabbitMQ中确保消息的可靠传输，包括交换器类型、消息持久化和消费者确认机制。最后，提到了RabbitMQ的集群和运维，如HAProxy负载均衡。
摘要由CSDN通过智能技术生成

JMS

字段名称含义
JMSDestination字段包含了消息要发送到的目的地。
JMSDeliveryMode字段包含了消息在发送的时候指定的投递模式。
JMSMessageID该字段包含了服务器发送的每个消息的唯一标识。
JMSTimestamp该字段包含了消息封装完成要发往服务器的时间。不是真正向服务器发送的时间，因为真正的发送时间，可能会由于事务或客户端消息排队而延后。
JMSCorrelationID客户端使用该字段的值与另一条消息关联。一个典型的场景是使用该字段将响应消息与请求消息关联.JMSCorrelationID可以包含如下值：
- 服务器规定的消息ID
- 应用指定的字符串
- 服务器原生的byte[]值
JMSReplyTo该字段包含了在客户端发送消息的时候指定的Destination。即对该消息的响应应该发送到该字段指定的Destination。设置了该字段值的消息一般期望收到一个响应。
JMSRedelivered如果这个字段是true，则告知消费者应用这条消息已经发送过了，消费端应用应该小心别重复处理了。
JMSType消息发送的时候用于标识该消息的类型。具体有哪些类型，由JMS实现厂商决定。
JMSExpiration发送消息时，其到期时间将计算为send方法上指定的生存时间值与当前GMT值之和。 从send方法返回时，消息的JMSExpiration标头字段包含此值。 收到消息后，其JMSExpiration标头字段包含相同的值。
JMSPriorityJMS定义了一个十级优先级值，最低优先级为0，最高优先级为9。 此外，客户端应将优先级0-4视为正常优先级，将优先级5-9视为快速优先级。JMS不需要服务器严格执行消息的优先级排序； 但是，它应该尽力在普通消息之前传递加急消息。

架构体系

  1. jms client : 生产和消费基于消息的java程序
  2. jms producer: 创建消息jms
  3. jms consumer: 接收消息的jms
  4. jms message: 在jms客户之间传递的数据对象
  5. jms queue: 容器
  6. jms topic

对象模型

  1. ConectionFactory(连接工厂):用户用来创建到JMS提供者的连接的被管对象。JMS客户通过可移植的接口访问连接，这样当下层的实现改变时，代码不需要进行修改。管理员在JNDI名字空间中配置连接工厂，这样，JMS客户才能够查找到它们。根据消息类型的不同，用户将使用队列连接工厂，或者主题连接工厂。
  2. Connection(连接):连接代表了应用程序和消息服务器之间的通信链路。在获得了连接工厂后，就可以创建一个与JMS提供者的连接。根据不同的连接类型，连接允许用户创建会话，以发送和接收队列和主题到目标。
  3. Destination(目标):目标是一个包装了消息目标标识符的被管对象，消息目标是指消息发布和接收的地点，或者是队列，或者是主题。JMS管理员创建这些对象，然后用户通过JNDI发现它们。和连接工厂一样，管理员可以创建两种类型的目标，点对点模型的队列，以及发布者/订阅者模型的主题。
  4. Session(会话):表示一个单线程的上下文，用于发送和接收消息。由于会话是单线程的，所以消息是连续的，就是说消息是按照发送的顺序一个一个接收的。会话的好处是它支持事务。如果用户选择了事务支持，会话上下文将保存一组消息，直到事务被提交才发送这些消息。在提交事务之前，用户可以使用回滚操作取消这些消息。一个会话允许用户创建消息，生产者来发送消息，消费者来接收消息。
  5. MessageConsumer 接口（消息消费者）:由会话创建的对象，用于接收发送到目标的消息。消费者可以同步地（阻塞模式），或（非阻塞）接收队列和主题类型的消息。
  6. MessageProducer 接口（消息生产者）:由会话创建的对象，用于发送消息到目标。用户可以创建某个目标的发送者，也可以创建一个通用的发送者，在发送消息时指定目标
  7. Message 接口（消息）:是在消费者和生产者之间传送的对象，也就是说从一个应用程序传送到另一个应用程序。一个
    消息有三个主要部分：
    • 消息头（必须）：包含用于识别和为消息寻找路由的操作设置。
    • 一组消息属性（可选）：包含额外的属性，支持其他提供者和用户的兼容。可以创建定制的字段和过滤器（消息选择器）。
    • 一个消息体（可选）：允许用户创建五种类型的消息（文本消息，映射消息，字节消息，流消息和对象消息）。
      在这里插入图片描述

AMQP

概念

  1. Publisher:消息发送者,将消息发送到Exchange并指定RoutingKey,一遍queue可以接收到指定消息
  2. Consumer:消息消费者,从queue获取消息,一个Consumer可以订阅多个queue已从多个queue中接收消息
  3. Server:一个具体的MQ服务实例,也称Broker
  4. Exchange:交换器,接收Publish发送过来的消息,把消息转发到对应的Message Queue中
  5. Routing key:路由键,用于指定消息规则(Exchange将消息路由到queue中),通常需要和具体的Exchange类型,Binding的Routing key结合起来使用
  6. Bindings:制定了Exchange和Queue的绑定关系,Exchange根据消息的Routing key 和Bingding配置(绑定关系,Binding,Routing key 等)来决定把消息分派到哪些具体的queue中,这依赖于Exchange类型
  7. Message Queue实际存储消息的容器,并把消息传递给最终的Consumer

各中间件比较

RabbitMQ

RabbitMQ开始是用在电信业务的可靠通信的，也是少有的几款支持AMQP协议的产品之一。

优点：
1. 轻量级，快速，部署使用方便
2. 支持灵活的路由配置。RabbitMQ中，在生产者和队列之间有一个交换器模块。根据配置的路由规则，生产者发送的消息可以发送到不同的队列中。路由规则很灵活，还可以自己实现。
3. RabbitMQ的客户端支持大多数的编程语言。
缺点
1. 如果有大量消息堆积在队列中，性能会急剧下降(索引存在文件中,数据过大,会导致遍历整个文件)
2. RabbitMQ的性能在Kafka和RocketMQ中是最差的，每秒处理几万到几十万的消息。如果应用要求高的性能，不要选择RabbitMQ。
3. RabbitMQ是Erlang开发的，功能扩展和二次开发代价很高。

RocketMQ

RocketMQ是一个开源的消息队列，使用java实现。借鉴了Kafka的设计并做了很多改进。RocketMQ主要用于有序，事务，流计算，消息推送，日志流处理，binlog分发等场景。经过了历次的双11考验，性能，稳定性可可靠性没的说。
RocketMQ几乎具备了消息队列应该具备的所有特性和功能。
java开发，阅读源代码、扩展、二次开发很方便。
对电商领域的响应延迟做了很多优化。在大多数情况下，响应在毫秒级。如果应用很关注响应时间，可以使用RocketMQ
性能比RabbitMQ高一个数量级，每秒处理几十万的消息

缺点：
跟周边系统的整合和兼容不是很好

Kafka

Kafka的可靠性，稳定性和功能特性基本满足大多数的应用场景。
跟周边系统的兼容性是数一数二的，尤其是大数据和流计算领域，几乎所有相关的开源软件都支持Kafka。
Kafka高效，可伸缩，消息持久化。支持分区、副本和容错。
Kafka是Scala和Java开发的，对批处理和异步处理做了大量的设计，因此Kafka可以得到非常高的性能。它的异步消息的发送和接收是三个中最好的，但是跟RocketMQ拉不开数量级，每秒处理几十万的消息。
如果是异步消息，并且开启了压缩，Kafka最终可以达到每秒处理2000w消息的级别。
但是由于是异步的和批处理的，延迟也会高，不适合电商场景。

在这里插入图片描述

RabbitMQ

逻辑架构

Exchange类型
  1. Fanout:会把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中
  2. Direct:direct类型的交换器路由规则很简单，它会把消息路由到那些BindingKey和RoutingKey完全匹配的队列中
  3. Topic:topic类型的交换器在direct匹配规则上进行了扩展，也是将消息路由到BindingKey和RoutingKey相匹配的队列中;BindingKey和RoutingKey一样都是由"."分隔的字符串；BindingKey中可以存在两种特殊字符“”和“#”，用于模糊匹配，其中"“用于匹配一个单词，”#"用于匹配多个单词
数据存储
  1. 持久化消息:同时写入磁盘和内存中
  2. 非持久化消息:当内存不够用时,将数据写入磁盘
    队列索引和消息存储
  3. rabbit_queue_index:索引使用顺序的段文件来存储，后缀为.idx，文件名从0开始累加，每个段文件中包含固定的segment_entry_count 条记录，默认值是16384。每个index从磁盘中读取消息的时候，至少要在内存中维护一个段文件，所以设置 queue_index_embed_msgs_below 值得时候要格外谨慎，一点点增大也可能会引起内存爆炸式增长。
  4. rabbit_msg_store:消息以键值对的形式存储到文件中，一个虚拟主机上的所有队列使用同一块存储，每个节点只有一
    个。存储分为持久化存储（msg_store_persistent）和短暂存储（msg_store_transient）。持久化存储的内容在broker重启后不会丢失，短暂存储的内容在broker重启后丢失。
    store使用文件来存储，后缀为.rdq，经过store处理的所有消息都会以追加的方式写入到该文件中，当该文件的大小超过指定的限制（file_size_limit）后，将会关闭该文件并创建一个新的文件以供新的消息写入。文件名从0开始进行累加。在进行消息的存储时，RabbitMQ会在ETS（Erlang TermStorage）表中记录消息在文件中的位置映射和文件的相关信息。

rabbit常用命令

# 前台启动Erlang VM和RabbitMQ
rabbitmq-server
# 后台启动
rabbitmq-server -detached
# 停止RabbitMQ和Erlang VM
rabbitmqctl stop
# 查看所有队列
rabbitmqctl list_queues
# 查看所有虚拟主机
rabbitmqctl list_vhosts
# 在Erlang VM运行的情况下启动RabbitMQ应用
rabbitmqctl start_app
rabbitmqctl stop_app
# 查看节点状态
rabbitmqctl status
# 查看所有可用的插件
rabbitmq-plugins list
# 启用插件
rabbitmq-plugins enable <plugin-name>
# 停用插件
rabbitmq-plugins disable <plugin-name>
# 添加用户
rabbitmqctl add_user username password
# 列出所有用户：
rabbitmqctl list_users
# 删除用户：
rabbitmqctl delete_user username
# 清除用户权限：
rabbitmqctl clear_permissions -p vhostpath username
# 列出用户权限：
rabbitmqctl list_user_permissions username
# 修改密码：
rabbitmqctl change_password username newpassword
# 设置用户权限：
rabbitmqctl set_permissions -p vhostpath username ".*" ".*" ".*"
# 创建虚拟主机:
rabbitmqctl add_vhost vhostpath
# 列出所以虚拟主机:
rabbitmqctl list_vhosts
# 列出虚拟主机上的所有权限:
rabbitmqctl list_permissions -p vhostpath
# 删除虚拟主机:
rabbitmqctl delete_vhost vhost vhostpath
# 移除所有数据，要在 rabbitmqctl stop_app 之后使用:
rabbitmqctl reset

用户标签和权限

TagCapabilities
(None)没有访问management插件的权限
management可以使用消息协议做任何操作的权限，加上：
1. 可以使用AMQP协议登录的虚拟主机的权限
2. 查看它们能登录的所有虚拟主机中所有队列、交换器和绑定的权限
3. 查看和关闭它们自己的通道和连接的权限<br4.>查看它们能访问的虚拟主机中的全局统计信息，包括其他用户的活动
policymaker所有management标签可以做的，加上：
1. 在它们能通过AMQP协议登录的虚拟主机上，查看、创建和删除策略以及虚拟主机参数的权限
monitoring所有management能做的，加上：
1. 列出所有的虚拟主机，包括列出不能使用消息协议访问的虚拟主机的权限
2. 查看其他用户连接和通道的权限
3. 查看节点级别的数据如内存使用和集群的权限
4. 查看真正的全局所有虚拟主机统计数据的权限
administrator所有policymaker和monitoring能做的，加上：
1. 创建删除虚拟主机的权限
2. 查看、创建和删除用户的权限
3. 查看、创建和删除权限的权限
4. 关闭其他用户连接的权限

使用

// 服务端
@Configuration
public class RabbitConfig {

    @Bean
    public ConnectionFactory connectionFactory() {
        return new CachingConnectionFactory(URI.create("amqp://root:123456@192.168.187.128:5672/%2f"));
    }

    // rabbitTemplate
    @Autowired
    @Bean
    public RabbitTemplate rabbitTemplate(ConnectionFactory connectionFactory) {
        return new RabbitTemplate(connectionFactory);
    }

    // rabbitAdmin
    @Autowired
    @Bean
    public RabbitAdmin rabbitAdmin(ConnectionFactory connectionFactory){
        return new RabbitAdmin(connectionFactory);
    }

    @Bean
    public Queue queue() {
        return QueueBuilder.nonDurable("queue.ex").build();
    }

    @Bean
    public Exchange exchange() {
        return new FanoutExchange("fanout.ex",false,false,null  );
    }

    @Bean
    @Autowired
    public Binding binding(Queue queue,Exchange exchange) {
        return BindingBuilder.bind(queue).to(exchange).with("key.ex").noargs();
    }
}

客户端

// 拉模式
@Configuration
public class RabbitConfig {

    @Bean
    public ConnectionFactory connectionFactory() {
        return new CachingConnectionFactory(URI.create("amqp://root:123456@192.168.187.128:5672/%2f"));
    }

    // rabbitTemplate
    @Autowired
    @Bean
    public RabbitTemplate rabbitTemplate(ConnectionFactory connectionFactory) {
        return new RabbitTemplate(connectionFactory);
    }

    // rabbitAdmin
    @Autowired
    @Bean
    public RabbitAdmin rabbitAdmin(ConnectionFactory connectionFactory){
        return new RabbitAdmin(connectionFactory);
    }

    @Bean
    public Queue queue() {
        return QueueBuilder.nonDurable("queue.ex").build();
    }

}

// 监听模式
    @Bean
    @Autowired
    public SimpleRabbitListenerContainerFactory simpleRabbitListenerContainerFactory(ConnectionFactory connectionFactory) {
        SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory();
        factory.setConnectionFactory(connectionFactory);
        factory.setAcknowledgeMode(AcknowledgeMode.AUTO);
        //并发获取消息
        factory.setConcurrentConsumers(10);
        factory.setMaxConcurrentConsumers(15);
        //按照批次消费消息
        factory.setBatchSize(10);
        return factory;
    }

  /**
     * com.rabbitmq.client.Channel channel对象
     * org.springframework.amqp.core.Message message对象 可以直接操作原生的AMQP消息
     * org.springframework.messaging.Message to use the messaging abstraction counterpart
     * @Payload 注解方法参数，改参数的值就是消息体
     * @Header 注解方法参数，访问指定的消息头字段的值
     * @Headers 该注解的方法参数获取该消息的消息头的所有字段，参数类型对应于map集合。
     * MessageHeaders 参数类型，访问所有消息头字段
     * MessageHeaderAccessor or AmqpMessageHeaderAccessor 访问所有消息头字段
     */
    @RabbitListener(queues = "queue.ex")
    public void whenMessageCome(Message message) throws UnsupportedEncodingException {
        System.out.println(new String(message.getBody(),message.getMessageProperties().getContentEncoding()));
    }

演示代码地址

消息可靠性
异常捕获机制

在这里插入图片描述

发送端确认机制
	RabbitMQ后来引入了一种轻量量级的方式，叫发送方确认(publisher confirm)机制。生产者将信道设置成confirm(确认)模式，一旦信道进入confirm 模式，所有在该信道上⾯面发布的消息都会被指派一个唯一的ID(从1 开始)，一旦消息被投递到所有匹配的队列之后（如果消息和队列是持久化的，那么确认消息会在消息持久化后发出），RabbitMQ 就会发送一个确认(Basic.Ack)给生产者(包含消息的唯一ID)，这样生产者就知道消息已经正确送达了。

channel.exchangeDeclare(EX_PUBLISHER_CONFIRMS, BuiltinExchangeType.DIRECT);
channel.queueDeclare(QUEUE_PUBLISHER_CONFIRMS, false, false, false, null);
channel.queueBind(QUEUE_PUBLISHER_CONFIRMS, EX_PUBLISHER_CONFIRMS,QUEUE_PUBLISHER_CONFIRMS);
String message = "hello";
channel.basicPublish(EX_PUBLISHER_CONFIRMS, QUEUE_PUBLISHER_CONFIRMS, null,
message.getBytes());
try {
	channel.waitForConfirmsOrDie(5_000);
	System.out.println("消息被确认：message = " + message);
} catch (IOException e) {
	e.printStackTrace();
	System.err.println("消息被拒绝！ message = " + message);
} catch (InterruptedException e) {
	e.printStackTrace();
	System.err.println("在不是Publisher Confirms的通道上使用该方法");
} catch (TimeoutException e) {
	e.printStackTrace();
	System.err.println("等待消息确认超时！ message = " + message);
}
持久化存储机制
	持久化是提高RabbitMQ可靠性的基础，否则当RabbitMQ遇到异常时（如：重启、断电、停机等）数据将会丢失。主要从以下几个方面来保障消息的持久性：
  1. Exchange的持久化。通过定义时设置durable 参数为ture来保证Exchange相关的元数据不不丢失。
  2. Queue的持久化。也是通过定义时设置durable 参数为ture来保证Queue相关的元数据不不丢失。
  3. 消息的持久化。通过将消息的投递模式 (BasicProperties 中的 deliveryMode 属性)设置为 2即可实现消息的持久化，保证消息自身不丢失。
    在这里插入图片描述
    RabbitMQ中的持久化消息都需要写入磁盘（当系统内存不不足时，非持久化的消息也会被刷盘处理理），这些处理理动作都是在“持久层”中完成的。持久层是一个逻辑上的概念，实际包含两个部分：
  4. 队列索引(rabbit_queue_index)，rabbit_queue_index 负责维护Queue中消息的信息，包括消息的存储位置、是否已交给消费者、是否已被消费及Ack确认等，每个Queue都有与之对应的rabbit_queue_index。
  5. 消息存储(rabbit_msg_store)，rabbit_msg_store 以键值对的形式存储消息，它被所有队列列共享，在每个节点中有且只有一个。
Consumer ACK
	前面我们讲了生产者发送确认机制和消息的持久化存储机制，然而这依然无法完全保证整个过程的可靠性，因为如果消息被消费过程中业务处理失败了但是消息却已经出列了（被标记为已消费了），我们又没有任何重试，那结果跟消息丢失没什么分别。
	RabbitMQ在消费端会有Ack机制，即消费端消费消息后需要发送Ack确认报文给Broker端，告知自己是否已消费完成，否则可能会一直重发消息直到消息过期（AUTO模式）。
	这也是我们之前一直在讲的“最终一致性”、“可恢复性” 的基础。
	一般而言，我们有如下处理手段：
1. 采用NONE模式，消费的过程中自行捕获异常，引发异常后直接记录日志并落到异常恢复表，再通过后台定时任务扫描异常恢复表尝试做重试动作。如果业务不自行处理则有丢失数据的风险
2. 采用AUTO（自动Ack）模式，不主动捕获异常，当消费过程中出现异常时会将消息放回Queue中，然后消息会被重新分配到其他消费者节点（如果没有则还是选择当前节点）重新被消费，默认会一直重发消息并直到消费完成返回Ack或者一直到过期
3. 采用MANUAL（手动Ack）模式，消费者自行控制流程并手动调用channel相关的方法返回Ack

/**
* NONE模式，则只要收到消息后就立即确认（消息出列，标记已消费），有丢失数据的风险
* AUTO模式，看情况确认，如果此时消费者抛出异常则消息会返回到队列中
* MANUAL模式，需要显式的调用当前channel的basicAck方法
* @param channel
* @param deliveryTag
* @param message
*/
@RabbitListener(queues = "lagou.topic.queue", ackMode = "AUTO")
public void handleMessageTopic(Channel channel,@Header(AmqpHeaders.DELIVERY_TAG) long deliveryTag, @Payload byte[] message) {
	System.out.println("RabbitListener消费消息，消息内容：" + new String((message)));
	try {
		// 手动ack，deliveryTag表示消息的唯一标志，multiple表示是否是批量确认
		channel.basicAck(deliveryTag, false);
		// 手动nack，告诉broker消费者处理失败，最后一个参数表示是否需要将消息重新
		入列
		channel.basicNack(deliveryTag, false, true);
		// 手动拒绝消息。第二个参数表示是否重新入列
		channel.basicReject(deliveryTag, true);
	} catch (IOException e) {
		e.printStackTrace();
	}
}

SpringBoot项目中支持如下的一些配置：

#最大重试次数
spring.rabbitmq.listener.simple.retry.max-attempts=5
#是否开启消费者重试（为false时关闭消费者重试，意思不是“不重试”，而是一直收到消息直到jack
确认或者一直到超时）
spring.rabbitmq.listener.simple.retry.enabled=true
#重试间隔时间（单位毫秒）
spring.rabbitmq.listener.simple.retry.initial-interval=5000
# 重试超过最大次数后是否拒绝
spring.rabbitmq.listener.simple.default-requeue-rejected=false
#ack模式
spring.rabbitmq.listener.simple.acknowledge-mode=manual
消费端限流
	RabbitMQ中有一种QoS保证机制，可以限制Channel上接收到的未被Ack的消息数量，如果超过这个数量限制RabbitMQ将不会再往消费端推送消息。这是一种流控手段，可以防止大量消息瞬时从Broker送达消费端造成消费端巨大压力（甚至压垮消费端）。比较值得注意的是QoS机制仅对于消费端推模式有效，对拉模式无效。而且不支持NONE Ack模式。执行channel.basicConsume 方法之前通过 channel.basicQoS 方法可以设置该数量。消息的发送是异步的，消息的确认也是异步的。在消费者消费慢的时候，可以设置Qos的prefetchCount，它表示broker在向消费者发送消息的时候，一旦发送了prefetchCount个消息而没有一个消息确认的时候，就停止发送。消费者确认一个，broker就发送一个，确认两个就发送两个。换句话说，消费者确认多少，broker就发送多少，消费者等待处理的个数永远限制在prefetchCount个。
	如果对于每个消息都发送确认，增加了网络流量，此时可以批量确认消息。如果设置了multiple为true，消费者在确认的时候，比如说id是8的消息确认了，则在8之前的所有消息都确认了。

在这里插入图片描述

@Bean
public RabbitListenerContainerFactory rabbitListenerContainerFactory(ConnectionFactory connectionFactory) {
	// SimpleRabbitListenerContainerFactory发现消息中有content_type有text
	就会默认将其
	// 转换为String类型的，没有content_type都按byte[]类型
	SimpleRabbitListenerContainerFactory factory = new
	SimpleRabbitListenerContainerFactory();
	factory.setConnectionFactory(connectionFactory);
	// 设置并发线程数
	factory.setConcurrentConsumers(10);
	// 设置最大并发线程数
	factory.setMaxConcurrentConsumers(20);
	return factory;
}
消息可靠性保障

消息可靠传输一般是业务系统接入消息中间件时首要考虑的问题，一般消息中间件的消息传输保障分为三个层级：
1. At most once：最多一次。消息可能会丢失，但绝不会重复传输
2. At least once：最少一次。消息绝不会丢失，但可能会重复传输
3. Exactly once：恰好一次。每条消息肯定会被传输一次且仅传输一次

可靠性分析
	在使用任何消息中间件的过程中，难免会出现消息丢失等异常情况，这个时候就需要有一个良好的机制来跟踪记录消息的过程（轨迹溯源），帮助我们排查问题。
	在RabbitMQ 中可以使用Firehose 功能来实现消息追踪，Firehose 可以记录每一次发送或者消费消息的记录，方便RabbitMQ 的使用者进行调试、排错等。
	Firehose 的原理是将生产者投递给RabbitMQ 的消息，或者RabbitMQ 投递给消费者的消息按照指定的格式发送到默认的交换器上。这个默认的交换器的名称为 amq.rabbitmq.trace ，它是一个topic 类型的交换器。发送到这个交换器上的消息的路由键为 publish.{exchangename} 和 deliver.{queuename} 。其中 exchangename 和 queuename 为交换器和队列的名称，分别对应生产者投递到交换器的消息和消费者从队列中获取的消息。
TTL(Time To Live超时机制)
RabbitMQ 可以对消息和队列两个维度来设置TTL。
任何消息中间件的容量和堆积能力都是有限的，如果有一些消息总是不被消费掉，那么需要有一种过期的机制来做兜底。
目前有两种方法可以设置消息的TTL。
	1. 通过Queue属性设置，队列中所有消息都有相同的过期时间。
	2. 对消息自身进行单独设置，每条消息的TTL 可以不同

try(Connection connection = factory.newConnection();Channel channel = connection.createChannel()) {
	// 创建队列（实际上使用的是AMQP default这个direct类型的交换器）
	// 设置队列属性
	Map<String, Object> arguments = new HashMap<>();
	// 设置队列的TTL,有效期是30000
	arguments.put("x-message-ttl", 30000);
	// 设置队列的空闲存活时间（如该队列根本没有消费者，一直没有使用，队列可以存活多久）
	arguments.put("x-expires", 10000);
	channel.queueDeclare(QUEUE_NAME, false, false, false, arguments);
	for (int i = 0; i < 1000000; i++) {
		String message = "Hello World!" + i;
		channel.basicPublish("",QUEUE_NAME,
			new AMQP.BasicProperties().builder().expiration("30000").build(),message.getBytes());
		System.out.println(" [X] Sent '" + message + "'");
	}
} catch (TimeoutException e) {
	e.printStackTrace();
} catch (IOException e) {
	e.printStackTrace();
}
死信队列
	在定义业务队列时可以考虑指定一个 死信交换机，并绑定一个死信队列。当消息变成死信时，该消息就会被发送到该死信队列上，这样方便我们查看消息失败的原因。
	DLX，全称为Dead-Letter-Exchange，死信交换器。消息在一个队列中变成死信（Dead Letter）之后，被重新发送到一个特殊的交换器（DLX）中，同时，绑定DLX的队列就称为“死信队列”。
	以下几种情况导致消息变为死信：
	1.  消息被拒绝（Basic.Reject/Basic.Nack），并且设置requeue参数为false；
	2.  消息过期；
	3.  队列达到最大长度。
	对于RabbitMQ 来说，DLX 是一个非常有用的特性。它可以处理异常情况下，消息不能够被消费者正确消费(消费者调用了Basic.Nack 或者Basic.Reject)而被置入死信队列中的情况，后续分析程序可以通过消费这个死信队列中的内容来分析当时所遇到的异常情况，进而可以改善和优化系统

@Configuration
public class RabbitConfig {
	@Bean
	public Queue queue() {
		Map<String, Object> props = new HashMap<>();
		// 消息的生存时间 10s
		props.put("x-message-ttl", 10000);
		// 设置该队列所关联的死信交换器（当队列消息TTL到期后依然没有消费，则加
		入死信队列）
		props.put("x-dead-letter-exchange", "ex.go.dlx");
		// 设置该队列所关联的死信交换器的routingKey，如果没有特殊指定，使用原
		队列的routingKey
		props.put("x-dead-letter-routing-key", "go.dlx");
		Queue queue = new Queue("q.go", true, false, false, props);
		return queue;
	}
	
	@Bean
	public Queue queueDlx() {
		Queue queue = new Queue("q.go.dlx", true, false, false);
		return queue;
	}
	@Bean
	public Exchange exchange() {
		DirectExchange exchange = new DirectExchange("ex.go", true,
		false, null);
		return exchange;
	}
	/**
	* 死信交换器
	* @return
	*/
	@Bean
	public Exchange exchangeDlx() {
		DirectExchange exchange = new DirectExchange("ex.go.dlx",
		true, false, null);
		return exchange;
	}
	
	@Bean
	public Binding binding() {
		return BindingBuilder.bind(queue()).to(exchange()).with("go").noargs();
	}

	/**
	* 死信交换器绑定死信队列
	* @return
	*/
	@Bean
	public Binding bindingDlx() {
		return BindingBuilder.bind(queueDlx()).to(exchangeDlx()).with("go.dlx").noargs();
	}
}
延迟队列
  1. TTL存放消息在死信队列(delayqueue)里
  2. 二基于插件存放消息在延时交换机里(x-delayed-message exchange)
@Bean
public Exchange exchange() {

	Map<String, Object> arguments = new HashMap<>();
	// 使用x-delayed-type指定交换器的类型
	arguments.put("x-delayed-type", ExchangeTypes.DIRECT);
	// 使用x-delayed-message表示使用delayed exchange插件处理消息
	return new CustomExchange("ex.delayed", "x-delayed-message", true, false, arguments);
}

RabbitMQ集群和运维

1.分片可以扩容
2.主备可以高可用

HAProxy负载均衡

支持四层,七层负载均衡

zhaojiadi1998
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
RabbitMQ架构篇 - Connection
The Secret
10-20 422
本文解析RabbitMQ的Connection结构。
RabbitMQ 中 Connection 和 Channel 详解
weixin_33768481的博客
01-27 1243
我们知道无论是生产者还是消费者，都需要和 RabbitMQ Broker 建立连接，这个连接就是一条 TCP 连接，也就是 Connection。 一旦 TCP 连接建立起来，客户端紧接着可以创建一个 AMQP 信道（Channel），每个信道都会被指派一个唯一的 ID。 信道是建立在 Connection 之上的虚拟连接，RabbitMQ 处理的每条 AMQP 指令都是通过信道完成的。 ...
rabbitmq-connection
zhongjay的专栏
11-29 531
一、ConnectionFactory ConnectionFactory factory = new ConnectionFactory();   开启一个连接，默认localhost和默认端口  factory.newConnection(addressAry);   二、newConnection   完整的方法签名： public Connection newConne...
RabbitMQ Connection Channel 详解
热门推荐
BIGBAI的博客
04-07 1万+
首先展示网络上的两种图： AMQP : Rabbit各关键组件交换流程： Rabbit 内部线程图： 1.ConnectionFactory、Connection、Channel ConnectionFactory、Connection、Channel都是RabbitMQ对外提供的API中最基本的对象。 Connection是RabbitMQ的socket链接，...
RabbitMQ：Connections的介绍和使用
编程学习者的博客
05-16 6143
1.声明 当前内容用于本人学习和复习之用，内容主要包括Connections的使用 当前内容主要来源：RabbitMQ官方文档 2.官方Connections介绍 AMQP 0-9-1 connections are typically long-lived. AMQP 0-9-1 is an application level protocol that uses TCP for reliable delivery. Connections use authentication and can be pr
PAcee1#myNote#04.RabbitMQ高级-消息100%投递成功方案1
07-25
1.消息入库，比如订单场景，当我们创建一条订单，需要发送消息给优惠券模块，来减少用户使用的优惠券 2.如果消息在第一步成功入库 3.MQ收到消息后返回结果响应
rabbitmq-server-3.12.13-1.el8.noarch.rpm
02-22
rabbitmq-server-3.12.13-1.el8.noarch.rpm下载，支持RPM for RHEL Linux 8.x and 9.x, CentOS Stream 8 and 9, Fedora 35+, Amazon Linux 2023, Rocky Linux, Alma Linux
RabbitMQ3.9.15安装包及安装文档
11-09
- 配置RabbitMQ：可能需要设置环境变量、修改配置文件（如`/etc/rabbitmq/rabbitmq.config`）以适应特定需求。 - 插件管理：RabbitMQ的许多功能通过插件实现，如管理控制台，可以使用`rabbitmq-plugins enable ...
RabbitMQ笔记
三分强势七分暖的博客
10-31 546
RabbitMQ笔记 一、消息中间件概述 1.什么是消息中间件 MQ全称为Message Queue， 消息队列(MQ)是一种应用程序对应用程序的通信方法。 消息队列就是基础数据结构中的“先进先出”的一种数据机构。 指的是程序之间通过消息发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。 2.消息中间件的作用 异步处理:将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度,提高系统的吞吐量。 解耦服务:不同进程（process）之间传递消息时，两个
RabbitMQ架构及特性
weixin_57349625的博客
06-27 1113
架构 Producer 生产者Exchange 交换器FanoutDirect 把消息路由到BingingKey 和RoutingKey 完全匹配的队列中TopicHeadersBindings 绑定(匹配)器 把exchange和queue按照路由规则绑定(匹配)起来Queues 队列Consumer 消费者自动确认手动确认可以和TTL配合实现延时队列 将消息设置ttl, 发送到死信队列中 (不设置消费者处理), 等待过期被转发到延时队列但该延时队列有缺陷, 若发送两条延时消息, 第一条延时10s,
RabbitMQ
weixin_41108644的博客
07-21 411
市面上比较火爆的几款MQ消息队列完成模块之间异步通讯，消息是不允许重复消费的，一条消息只能被消费一次。语言的支持ActiveMQ，RocketMQ只支持Java语言，Kafka可以支持多们语言，RabbitMQ支持多种语言。效率方面ActiveMQ，RocketMQ，Kafka效率都是毫秒级别，RabbitMQ是微秒级别的。消息丢失，消息重复问题RabbitMQ针对消息的持久化，和重复问题都有比较成熟的解决方案。学习成本RabbitMQ非常简单。递异步消息。...
RabbitMq(二) Connection、Channels、Exchanges、Queues 等基本概念介绍
liuhenghui5201的专栏
06-03 9333
一、Connection 、Channel、Queue等之间关系 在Mq中connection以及Channel Exchange Queue 是什么样的关系，我们可以从下图可以可以进行了解，图片来自黑马公开课视频。我们不管作为消息的生产者（Producer）或者消费者（Consumer）都是作为客户端（Client）连接到MQ服务器（Blocker Node）上。在生产者和消费者与RabbitMQ-Server 之间都是通过Connection进行连接。在Connection中存在Chan...
根据源码，模拟实现 RabbitMQ - 网络通讯设计，实现客户端Connection、Channel（完结）
CYK_byte的博客
08-24 1384
根据源码，自己手敲一个 RabbitMQ？
Spring项目集成RabbitMQ及自动创建队列
邢慧鹏的博客
02-21 7582
简单记录项目集成RabbitMQ的过程，及项目启动自动创建队列
SpingBoot 集成RabbitMQ使用@Bean 注解无法在项目启动时在MQ服务器端创建队列
勿忘初心的博客
09-18 1809
【代码】SpingBoot 集成RabbitMQ使用@Bean 注解无法在项目启动时在MQ服务器端创建队列。
RabbitMQ基础知识
J789456_154的博客
04-02 197
我了解到的是，mq（message queue）既消息队列，他可以加速消息的传输，举个例子。例如：在淘宝网买手机，一时间有成千上万的提交量，这时候就会用到mq，可以完成大量数据的交易，保证订单的无误性。RobbitConfig是一些通道的配置，这里也体现了springboot的便捷，可以不用配置工厂。，至于为什么非要写到test中，这个是固定的，写那里其实无所谓但是写到test是普遍认同的。先建立maven工程。第三部分：创建消费者！有两个监听者，和一个发布者，例如：一个up主，2个粉丝的关系。
RabbitMQ 最常用的三大模式
最新发布
2401_84049200的博客
04-16 634
/2. 通过连接工厂来创建连接//3. 通过 Connection 来创建 Channel//4. 声明//一般不用代码绑定，在管理界面手动绑定//5. 创建消费者并接收消息@Override//6. 设置 Channel 消费者绑定队列可以使用通配符进行模糊匹配符号’#" 匹配一个或多个词符号"*”匹配不多不少一个词例如:'log.#“能够匹配到’log.info.oa”"log.*"只会匹配到"log.erro“
rabbitmq创建缓存连接工厂
PacosonSWJTU的博客
03-21 1489
转自： 【RabbitMQ-3】连接池的配置_小胖学编程的博客-CSDN博客文章目录1. rabbitmq的connection连接池1.1 问题提出1.1.1 Connection对象管理以及性能1.1.2 Channel对象管理以及性能1.2 Spring AMQP线程池配置1.2.1 ConnectionFactory连接工厂1.2.2 消费发送和接收使用不同的Connectionjava NIO是IO的多路复用，Channel连接是TCP的多路复用。那么他们有什么关系呢？NIO是服务器开启一个线程
SpringBoot 集成 RabbitMQ
Listening_Wind的博客
01-28 600
SpringBoot 集成 RabbitMQ 简介 RabbitMQ是基于AMQP（Advanced Message Queuing Protocol）协议标准开发规范的一种消息投递服务，主要应用场景 异步处理、应用解耦、流量削峰。 RabbitMQ 名词 Broker : 它提供一种传输服务,它的角色就是维护一条从生产者到消费者的路线，保证数据能按照指定的方式进行传输,。 vhost : 虚拟主机,一个broker里可以有多个vhost，用作不同用户的权限分离。 Exchange ：消息交换器,它
spring.rabbitmq
08-18
在这个测试类SpringAmqpTest中，我们使用了RabbitTemplate来实现消息的发送。首先，我们引入了相应的依赖并进行了必要的注解配置。在测试方法testSimpleQueue中，我们指定了队列的名称和要发送的消息，并调用rabbitTemplate的convertAndSend方法来发送消息。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *2* [RabbitMQ消息中间件快速入门](https://blog.csdn.net/mmmmmCJP/article/details/118899317)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_1"}}] [.reference_item style="max-width: 50%"] - *3* [SpringBoot使用RabbitMQ消息队列](https://blog.csdn.net/qq_18395585/article/details/101278709)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_1"}}] [.reference_item style="max-width: 50%"] [ .reference_list ]
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值