消息队列 on Coder_Studio

RabbitMQ怎么实现延迟消息

Sat, 17 Jan 2026 18:19:27 +0000

在RabbitMQ中，实现延迟消息可以通过死信交换机（DLX）+过期时间（TTL）的方案，也可以采用RabbitMQ官方提供的延迟消息插件。

DLX+TTL。

主要步骤如下：

1.声明并创建普通交换机和普通队列，完成二者的绑定。

2.声明并创建死信交换机和死信队列，也完成二者的绑定。

3.指定当前普通队列的死信要转发到哪个DLX，以及要匹配哪个死信路由键。

4.不给普通队列配置任何的消费者，使普通队列只做消息暂存和过期，不消费。

5.在生产者发送消息时，为消息设置TTL，将消息发送到普通队列和普通交换机。

6当消息在普通队列的存活时间达到TTL后，过期的消息会被自动转发到DLX中，DLX再重新路由到死信队列，从死信队列中发送的消息就是延迟消息。

rabbitmq_delayed_message_exchange插件

主要步骤：

1.将插件放到RabbitMQ的plugins目录

2.执行rabbitmq-plugins enable rabbitmq_delayed_message_exchange命令启用插件

3.声明一个延迟交换机

4.声明一个普通队列并绑定该延迟交换机

5.生产者在发送消息时，设置消息投x-dlay:延迟时间(ms)

说说RabbitMQ的集群模式

Thu, 15 Jan 2026 17:21:36 +0000

RabbitMQ的集群主要分为标准集群、镜像集群和联邦集群三种。

标准集群

标准集群是多台RabbitMQ服务器通过网络连接组成一个集群，所有节点共享元数据，但是一个消息只存储在单个节点上。

在标准集群模式下，因为元数据是共享的，所以任何一个节点都知道消息在哪个节点上，可以实现负载均衡。

消息存储在某个节点上但是不会自动复制到其他节点。

镜像集群

和标准集群模式不同，镜像集群模式下，队列的消息会复制到多个节点上，如果主队列所在的节点发生故障，副本节点会自动接管，从而保证队列的可用性。

Federated 集群

通过Federated Exchange或Federated Queue实现消息的跨节点路由 / 复制，节点之间无需共享元数据，解决了标准 / 镜像集群无法跨广域网部署的问题。

什么是RabbitMQ中的死信队列

Mon, 12 Jan 2026 14:44:12 +0000

在消息队列系统中，死信队列（Dead Letter Queue,DLQ）是一种处理无法正常消费的消息的机制。

RabbitMQ 中实现死信机制的核心是死信交换机（Dead Letter Exchange, DLX），绑定该交换机的队列就是死信队列。

死信队列是用来接收那些被拒绝的、过期的或者已经达到最大传递次数的消息。

可以通过给队列设置x-dead-letter-exchange 参数来指定死信交换机，搭配x-dead-letter-routing-key指定死信路由键，从而实现死信队列的绑定。

怎么在RabbitMQ中配置消息的TTL

Mon, 12 Jan 2026 14:17:02 +0000

TTL（Time To Live）表示消息在队列中存活的时间，主要用于防止消息在队列中无限积压，导致系统资源的耗尽。

配置TTL有两种方式，一种是队列级别的TTL，另外一种是消息级别的TTL。

1.在声明队列时通过设置x-message-ttl参数来指定队列中所有消息的TTL。

2.在发送消息时通过AMQP.BasicProperties属性指定单个消息的TTL。

RabbitMQ中的Prefetch参数

Sun, 11 Jan 2026 17:07:58 +0000

在RabbitMQ中，prefetch参数主要是用于限制消费者端可以同时预取并未确认消息的最大数量，帮助消费者端控制消息处理的流量。

举个例子说明一下：

如果prefetch的参数设置为1，那么消费者会在未确认消息之前，只预取一个消息，这样可以确保每个消息在被处理成功之后，才接收下一个消息，从而避免消息的积压和资源耗尽。

在负载均衡、避免内存溢出以及优先级处理这些场景下会用到prefetch参数的设置。

比如：

1.RabbitMQ默认轮询分发消息，消费者可以根据其处理能力进行动态地调整prefetch值，实现基于处理能力的动态负载均衡。

2.如果有大量未处理的消息堆积在内存中可能会导致内存溢出，这时通过设置一个较小的prefetch值可以避免这种情况。

3.配合RabbitMQ的优先级队列，设置prefetch值可以确保队列优先推送高优先级的消息，让其被及时处理。

注意⚠️：

prefetch仅在消费者手动确认消息模式下生效。

RabbitMQ的消息确认机制是怎么工作的

Sat, 10 Jan 2026 16:33:38 +0000

RabbitMQ的消息确认机制主要是用于确保消息的可靠传递，防止消息丢失。

通过发布确认和消费者确认来实现。

发布确认

当生产者发送消息到RabbitMQ时，可以选择开启发布确认模式，当RabbitMQ成功将消息入队/持久化之后，会发送一个ACK回复生产者，告知消息成功到达队列；仅当消息处理失败时会返回NACK。

如果生产者在合理的时间内没有收到ACK或者NACK，则可以重发消息。

消费者确认

消费者在处理完一条消息之后，必须发送一个ACK给RabbitMQ，告知RabbitMQ该消息已经处理完成，RabbitMQ在收到ACK之后会将该消息从队列中永久删除。

如果RabbitMQ在收到消费者ACK之前检测到消费者已经断开连接，则认为该消息没有被成功处理，RabbitMQ会重新发送给其他消费者消费。

在RabbitMQ中-怎么确保消息不会丢失

Thu, 08 Jan 2026 17:15:44 +0000

为了确保消息不会丢失，可以从以下3个方面解决：

1.在创建队列的时候设置durable为true，发布消息的时候设置delivery为2，从而确保队列和消息都是持久的。

这样，就算是RabbitMQ服务器重启也不会造成消息的丢失。

2.开启发布确认模式，这样的话，生产者会等待服务器的确认响应，确保消息已经成功存储。

3.使用明确的消费者确认机制，当消费者处理完消息之后，向RabbitMQ发送确认，只有在RabbitMQ收到消费者发来的确认之后才会将消息从队列中删除。

RabbitMQ的交换机有哪几种类型

Tue, 06 Jan 2026 17:52:56 +0000

RabbitMQ是一个可实现异步通信和任务解耦的消息队列系统。

主要有Direct、Fanout、Topic、Headers这4种类型。

Direct	根据消息的routing key精确匹配binding key，只有完全匹配的消息才会被转发到对应的Queue	适合像日志系统这种需要精确匹配的场景
Fanout	不考虑routing key，直接将接收到的每一条消息都广播到所有绑定到它的Queue	适合广播消息，比如社交媒体的消息推送
Topic	根据消息的routing key和binding key的模式匹配决定消息的流转路径	适合需要根据特定模式进行消息路由的场景，比如订单系统
Headers	根据消息的头部属性来路由，提供更加复杂和灵活的路由策略	适合需要更复杂路由逻辑的场景，比如不同部门处理的邮件系统

说说RabbitMQ的基本架构

Mon, 05 Jan 2026 15:37:48 +0000

RabbitMQ的架构有以下6个关键组件：

Producer	生产者	主要负责生产消息并发送给RabbitMQ
Exchange	交换机	生产者发过来的消息并不是直接投进队列，而是交给Exchange，让Exchange根据消息中的Routing Key来决定把它扔进哪个队列
Queue	队列	这是消息最终存放的地方，在这里等待被取走
Binding	绑定	把Exchange和Queue连接起来，告诉交换机这个消息需要扔进哪个队列
Consumer	消费者	从Queue中取出消息并处理
Virtual Host	虚拟主机	VHost之间是完全隔离的，互不影响，通常用于区分不同的业务线

如果把RabbitMQ比作快递物流系统，那么6个关键组件分别对应的角色如下：

生产者是发件人，交换机是快递分拣中心，队列就是快递仓库，绑定就是分拣规则表，消费者就是收件人，虚拟主机就是快递分公司。

注意⚠️：

一个消息可以被拷贝到多个Queue，但是一个队列里的消息只能被消费一次。

A2A协议和MCP协议的关系

Mon, 05 Jan 2026 13:34:53 +0000

在AI生态系统中，A2A协议和MCP协议是两个扮演着不同角色但是又互补的标准协议。

A2A（Agent to Agent）协议是一个应用层协议，允许不同的AI智能体以“智能体”或者“用户”的身份进行交流，更关注智能体之间的沟通和协作。

MCP（Model Context Protocol）协议则提供了AI模型与外部的数据源和工具的标准化连接方式，允许AI模型通过统一的接口访问文件、数据库、API等资源。

A2A类似于一个电话簿，目的是让不同的AI智能体可以相互联系和协作；

而MCP则类似于一个工具说明书，主要是为了告诉AI模型怎么使用外部的工具和数据。

聊聊RabbitMQ

Sun, 04 Jan 2026 16:07:46 +0000

RabbitMQ是一个开源的消息中间件。

如果没有RabbitMQ，系统A直接把数据传给系统B，这样当B忙不过来或者挂了的时候，A就会卡死或者造成数据丢失。

但是，如果有了RabbitMQ，系统A可以把数据传给RabbitMQ，而RabbitMQ则负责把数据暂存起来，再按照系统B的处理能力，稳稳地传送给B。

RabbitMQ主要有3大应用场景：

1.比如在实现用户注册功能时，通过引入RabbitMQ进行异步处理，可以提升响应的速度：

没有引入RabbitMQ时，在注册完之后，需要同步地发邮件和短信，这样用户可能需要等几秒钟才能看到“注册成功”。

引入RabbitMQ之后，把注册的信息写入数据库之后，可以直接把“发送邮件”和“发送短信”这两个任务扔给RabbitMQ，这样就能够立刻给用户返回“注册成功”。

2.我们平常网购的时候，应该也会注意到，买东西的次数多了，某宝或者某东、某多的积分也会相应增加。

这也就是下单场景的积分累加。

想象一下如果订单系统直接调用积分接口，一旦积分系统挂了，那订单也下不了了。

有个大佬说过这样一句话：

没有什么是加一层中间层不能解决的，如果有，那就再加一层。

所以，中间加个RabbitMQ，这样订单系统只需要把“我要下单”的消息发送给RabbitMQ，而积分系统什么时候恢复那就什么时候再去取消息，从而累加积分。

通过这样引入RabbitMQ，可以实现应用之间的解耦，从而降低系统的依赖。

3.在双十一的秒杀场景下，通常会有几百上千万的请求在一瞬间涌进来，这个时候数据库可能就直接崩了。

通过引入RabbitMQ，先把请求全部扔进RabbitMQ排队，后台系统再按照自己的节奏从RabbitMQ中拉取请求进行处理，从而实现流量削峰，保护数据库的作用。

什么是循环依赖

Mon, 29 Dec 2025 16:48:25 +0000

循环依赖是指两个或者多个bean之间相互引用，形成了一个闭环。

最典型的场景就是：

比如Spring正在创建Bean A，发现它依赖B，于是就去创建B，结果在创建B的时候，又发现它依赖A。

但是这个时候A正在创建中，还没有完全生成，这样B就拿不到A的引用，所以该咋办呢？

这里又分为构造器注入和Setter注入两种情况：

如果是构造器注入，那好办，Spring直接就给你抛出BeanCurrentlyInCreationException错误。

如果是Setter注入，Spring则是通过三级缓存机制来解决。

Kafka的索引设计有什么亮点

Mon, 29 Dec 2025 16:31:00 +0000

Kafka索引设计的亮点主要有以下4个方面：

1.kafka通过稀疏索引只存储每隔一定间隔的消息位置，而不是对每条消息都建立索引，这样可以大幅度减少内存的占用。

2.Kafka通过将日志文件拆分成多个段文件来存储，每个段文件中包含一个日志文件和对应的索引文件。

3.kafka为了降低磁盘的随机写入成本，采用顺序写入文件的方式，提升了写入性能。

4.Kafka为了避免逐个扫描，通过offset定位消息，再结合稀疏索引可以快速定位到近似位置后再进行顺序查找，从而保证高效地读取。

kafka中的时间轮实现

Mon, 29 Dec 2025 15:49:00 +0000

Kafka中的时间轮是一种用于实现定时清理、消息过期、心跳超时等功能的定时任务调度机制。

通过时间轮可以避免在大量的定时任务中进行逐个扫描，可以实现接近O(1)的延迟任务管理，降低了内存和CPU的消耗，比较适合管理大量短时和中长期的定时任务。

时间轮，它可以看成是一个环形数组，其中，每个槽表示一个时间间隔。

Kafka会在时间轮的每个槽中根据任务的到期时间放置延迟任务，当时间轮转到任务所在的槽时，就执行该槽内的任务。

如果存在到期未完成的任务，则会被重新分配到下一轮。

Kafka中关于事务消息的实现

Mon, 29 Dec 2025 15:06:48 +0000

Kafka的事务消息实现了消息在生产、传输和消费的过程中的“仅一次”传递，也就是所谓的Exactly Once语义。

Kafka的事务消息主要由事务协调器、幂等生产者和事务性消费这三个核心组件来实现。

事务协调器主要负责事务的启动、提交和终止管理，将事务状态记录到__transaction_state内部的主题；

为了确保同一事务的每条消息只写入一次，Kafka Producer通过Producer ID来作为事务的唯一性标志。

在消费的过程中，消费者可以选择只消费已提交的事务消息，从而确保数据的最终一致性。

我们可以理一下Kafka的事务消息流程：

首先是生产者向Transaction Coordinator请求启动事务；

接下来生产者为了保证幂等性，给每条消息都带上唯一的Producer ID和Sequence Number，开始向Kafka写入事务消息；

当所有消息都写入完成后，生产者开始向事务协调去发送commit或者abort请求提交或者终止事务。

最后，消费者为了实现最终的数据一致性，可以通过设置read_commited 隔离级别，只消费已提交的消息。

RocketMQ的事务消息有什么缺点你知道吗

Sun, 28 Dec 2025 17:01:10 +0000

RockMQ事务消息的缺点主要就以下几个方面：

从改造成本来看，RocketMQ需要改造它的原始逻辑来实现一个特定的接口，并且还需要在应用层来处理一个复杂的回查逻辑，从而确保回查不会重复或者丢失。

在可用性方面，由于RocketMQ的事务消息的实现是先发送半消息，如果MQ集群挂了，那么半消息就没法发送成功，后续的逻辑就无法再执行下去了，也就是说整个应用无法正常执行了。

还有一个缺点就是RocketMQ只支持单事务消息。

说说消息队列的推模式和拉模式

Sun, 28 Dec 2025 16:28:14 +0000

推模式是消息队列主动将消息从Broker推送给Consumer，这种模式它的实时性比较好，消息可以立即送达消费者，但是缺点就是决定权不在消费者手上，在高并发场景下容易造成消费者过载。

拉模式是消费者主动从消息队列中的Broker拉取消息，这种模式就是根据消费者自身的负载和消费能力来决定拉去消息的频率，这样就可以避免过载，但是这种模式的实时性比不上推模式，而且还会导致消息延迟。

RocketMQ和Kafka都选择了拉模式，对于拉模式无法保证实时性的缺点，他们采取的是长轮询的方式来解决。

主要是通过在消费者去Broker拉取消息时，当有消息存在的话，那自然就直接返回消息；当没有消息时，则保持连接，暂时hold住请求，之后如果在对应的队列或者分区有新的消息到来时就通过之前hold住的请求及时地返回消息。

消息队列如何处理消息堆积

Sun, 28 Dec 2025 15:14:44 +0000

在消息队列中，当消息的生产速度远远大于消费速度时，将会导致大量的消息积压在队列中，这样就会形成消息堆积。

那如何处理消息堆积呢？

一般来说，我们需要定位一下消费慢的原因，如果是bug则处理bug；如果是因为消费者自身的消费能力弱，则需要考虑提升消费者的消费能力。

那怎么提高消费者的消费能力呢？

1.可以考虑增加消费者的线程数量，提高消费者的并发消费能力；

2.如果是在分布式系统中，可以增加多个消费实例，从而提高消费速率。

3.优化消费者的代码，比如可以减少I/O操作或者使用批量处理等等。

上面这些是通过消费者端进行解决的方法，如果是从生产端解决的话，可以考虑对生产端进行限流，降低生产速率。

消息队列如何保证消息的有效性

Sat, 27 Dec 2025 17:56:38 +0000

为了保证消息的有效性，可采取如下方法：

1.为了确保消息按照生产者的发送顺序来消费，可以使用单个生产者向单个队列发送消息，再由单个消费者来处理消息。

2.对于像Kafka和RocketMQ这种支持分区的消息队列，可以通过Partition Key将消息发送到一个特定的分区。因为每个分区的内部都是有序的，这样一来就能保证具有相同Partition Key的消息都按照顺序来消费。

3.对于像RabbitMQ这种支持顺序队列的消息队列，因为消息在队列中的存储顺序和投递顺序都是一致的，如果使用单个顺序队列，那么消息也将按照顺序被消费。

消息队列如何处理重复消息

Sat, 27 Dec 2025 17:03:04 +0000

对于平常的业务而言，消息重复一般是不可避免的，我们只能在业务上来处理重复消息所带来的影响。

为了保证同一条消息无论被消费多少次，它的结果都是一样的，需要让消费者的处理逻辑具有幂等性。

为了实现幂等处理重复消息，可以给每条消息分配一个全局的唯一ID，当消费者接收消息时，先检查一下这个ID是否已经处理，如果已经处理则直接返回，如果没有处理，则执行逻辑并记录一下ID。

除了分配全局唯一ID，对于订单数据来说，还可以设计一个严格的状态流转（比如：待支付→已支付→待发货→已发货），这样在每次处理消息前对当前状态进行检查，看是否符合操作条件。

消息队列如何保证消息不丢失

Sat, 27 Dec 2025 16:15:36 +0000

为了保证消息不丢失，需要生产消息、存储消息和消费消息这三个阶段协同配合。

当生产者在发送消息时，需要通过消息确认机制来确保消息的成功到达。

我们知道存储在内存中的消息是断电不保存的，因此，为了避免消息因为服务器的宕机或者重启而丢失，需要在Broker收到消息后，将其持久化到磁盘中。

在消费者处理完消息后，需要向消息队列发送确认，如果没有收到消费者发送过来的确认，消息队列则需要重新投递该消息。

说一下消息队列有哪些模型

Sat, 27 Dec 2025 15:36:30 +0000

常见的消息队列模型主要有发布/订阅模型和队列模型（也称点对点模型）两种。

那什么是队列模型呢？所谓的队列模型，指的是消息从生产者发送到队列中，其中的消息只能被一个消费者消费一次，在消费者消费完之后，消息就在队列中被删除了。

而发布/订阅模型，则指的是生产者将消息发布到某个Topic中，这样所有订阅了这个主题的消费者都可以接收到这个消息，这种模型比较适用于像广播通知和实时推送这样的场景。

需要说明的是，RabbitMQ虽然具有发布/订阅模式，但是在本质上RabbitMQ还是通过同时将消息发送给多个队列来模拟出发布/订阅的效果，其底层依然是基于队列模型的。

而RocketMQ和Kafka则都是采用发布/订阅模型的。

解释一下什么是消息队列

Sat, 27 Dec 2025 14:42:56 +0000

消息队列是一种用于在分布式系统中，解耦发送方和接收方之间通信的异步通信机制。

消息队列通过引入一个broker作为中间缓冲区，然后将消息存储在broker中，接下来再由消费者从broker中读取和处理消息，从而实现异步通信。

消息队列常见的用途主要有：

1.生产者可以在发送消息之后立即返回，而消费者也可以在恰当的时机对消息进行处理。

2.在高并发的场景下，消息队列可以暂时存储大量的请求，平滑高峰期的流量，不至于使系统过载。

3.为了减少用户请求的响应时间，可以选择将不需要立即处理的任务放入消息队列中异步执行。

说说RocketMQ中关于事务消息的实现

Fri, 26 Dec 2025 16:46:06 +0000

在RocketMQ中，为了确保消息与本地事务的一致性，生产者会先将消息发送到RocketMQ的Topic中，这个时候消息的状态为半消息，对于消费者来说，还是不可见的。

接下来，生产者会执行本地事务：

如果本地事务成功了，生产者就会向RocketMQ执行commit操作，将半消息转变为正式消息，这样消费者就可见了。

如果本地事务失败了，生产者就会向RocketMQ执行Rollback操作，然后RocketMQ就会丢弃这个半消息。

如果生产者没有及时地执行commit或者rollback操作，那么RocketMQ就会定时地回查本地事务的状态，从而来决定是否commit或者rollback消息。