RabbitMQ在微服务即时通讯中的核心角色与实战指南

开头先讲个我自己的经历。去年团队把一个单体聊天后端拆成微服务，第一版没引入任何消息中间件，直接用HTTP接口互相调。结果上线第一天就出了大问题：用户A给用户B发消息，消息先进了网关服务，网关再同步调消息服务存库，库存完了再同步调推送服务找B的连接。这一条链走下来，动静大、延迟高不说，推送服务一重启，中间那几步全断，消息就丢了。后来我们把RabbitMQ引入链路，才真正把这个问题理顺。这篇就围绕微服务即时通讯场景，把我对RabbitMQ的理解、配置经验、踩过的坑一次讲清楚。

这篇文章适合谁看？如果你的系统架构已经切到微服务，正打算做或正在做IM类功能（好友聊天、群聊、系统通知、客服会话都在范围内），又或者你只是听说RabbitMQ能解耦但不知道它到底解了什么，那这篇文章正好对症。我会从原理讲到代码，再到可靠性配置和运维实操，尽量不用一句废话。

1. 只靠HTTP轮询做不了真正的即时通讯

1.1 单体时代，聊天功能为什么"简单"

在单体架构里做聊天，本质上是很直白的一件事：客户端和服务器维持一条长连接（WebSocket或TCP），服务器收到一条消息，查一下接收方在不在线，在线就直接从连接池里找到那个连接推过去，不在线就存库等下次上线拉取。这个流程所有状态都在一个进程内，查连接、发消息、写库都不涉及跨服务调用，所以看起来根本不需要消息队列。

但这里有个隐藏前提：消息的收发、连接的管理、好友关系的查询，全都耦合在一个应用里。一旦这个应用的所有功能都部署在同一台机器或同一个进程内，一切好说；可一旦要拆分，问题就不一样了。

1.2 微服务拆分后，消息链路变成了"接力赛"

微服务化之后，典型的IM系统会被拆成这些服务：

• 接入网关服务：维护客户端长连接，负责消息的收发、心跳
• 消息服务：负责消息的存储、拉取、未读数、已读回执
• 用户关系服务：维护好友关系、群成员关系
• 推送服务：把消息推到客户端App、浏览器或短信通道

这时候用户A给B发一条消息，消息的流转变成了这样：A连接的是网关实例1，B可能连接在网关实例5上，A的消息要先从网关1出去，经过消息服务存库，再经过推送服务，最后才能找到网关5上的B。每一步都要经过一次网络调用，链路过长导致延迟变大；更麻烦的是，在微服务架构里，网关实例是会扩缩容的，你永远无法提前知道B连接在哪台机器上，所以服务之间必须有一种"发现对方"的机制。

1.3 RabbitMQ解决的核心问题是什么

前面说的链路困境，本质上是两个问题：服务与服务之间的同步调用太重、消息的投递没有中间缓冲层。RabbitMQ在这里做的核心事情，就是把"一个服务直接调用另一个服务"变成"一个服务把消息丢给队列，另一个服务自己去队列里取"。

这个转变带来三个直接好处：

• 发送方不需要关心接收方是谁、在哪台机器、挂了没有，只要确保消息进了队列就算成功。
• 消费方可以根据自己的处理能力慢慢消费，而不是被高并发请求打爆。
• 消息在队列里可以持久化，即使接收方服务重启，消息也不会丢，重启后还能继续消费。

用一个生活化的类比就是：原来你寄快递必须当面递给收件人，收件人不在你就白跑一趟；有了RabbitMQ这个"快递柜"，你把快递放进柜子里，收件人什么时候方便什么时候来取，柜子不会丢件，收件人换了手机号也没关系，只要柜子还在就行。

2. 拆解RabbitMQ在即时通讯中的四种角色定位

引入RabbitMQ不是为了让架构图好看，它在这套体系里实打实扮演了四个角色：流量缓冲器、服务解耦器、消息路由器和状态广播器。下面逐个展开。

2.1 削峰填谷：扛住群聊和系统通知的瞬时洪峰

即时通讯里最怕的不是点对点消息，而是群聊和全员通知。一个500人的大群，有人发一条消息，一瞬间就要生成500条投递任务；后台系统发一条全员公告，可能同时压向几十万在线用户。如果这些投递任务直接打到各个业务服务上，服务很容易被瞬时流量打崩。

RabbitMQ在这里做的是削峰填谷：生产者（消息服务）把投递任务一股脑丢进队列，消费者（推送服务）按照自己设定的速率一条一条处理。你可以把推送服务的消费并发数调低一点，宁可推得慢一点，也不能让服务被压垮。这个缓冲能力在秒杀、营销活动、直播间公告等瞬时压力极大的场景下尤其明显。

实际配置时，推送服务的并发消费者数量需要根据下游推送通道（比如APNs、极光推送、自建推送通道）的吞吐能力来设定，通常建议从低往高调，观察队列堆积量和推送延迟，找到一个平衡点。太多会导致下游通道被频繁限流，太少又会造成消息堆积。

2.2 服务解耦：上下游互不感知，独立扩缩容

微服务架构最大的痛点之一就是依赖。如果不加消息队列，消息服务要调用推送服务的HTTP接口，推送服务升级接口、变更地址、缩容，消息服务都得跟着改配置、改代码。更麻烦的是，如果以后要新增一个"消息同步到搜索服务"或者"消息统计服务"的需求，原来的消息服务还得改代码去调用新的服务。

引入RabbitMQ之后，消息服务只负责把消息投递到交换机，至于谁在消费这些消息，它完全不需要知道。推送服务在消费，搜索服务在消费，甚至未来新加的AI分析服务也在消费，这些对消息服务来说都是透明的。

这种解耦还有一个实际好处：新服务上线时不需要改旧服务的代码和配置。比如你新加了一个"敏感词异步扫描服务"，只需要写一个消费者订阅同一队列，然后在RabbitMQ管理后台把队列和交换机绑定好，它就可以开始工作了，消息服务一行代码都不用动。这对我们这种经常要加功能迭代的团队来说，省下的沟通和发版成本是实实在在的。

2.3 消息路由：不同投递模式的灵活实现

RabbitMQ最强大的地方在于它灵活的路由模型。它不像Kafka那种只要写入Topic就完事，RabbitMQ的消息要经过交换机（Exchange），由交换机根据路由键（RoutingKey）决定消息进入哪个队列。这套机制用在IM场景里，正好可以覆盖各种消息类型：

• 点对点聊天：用Direct交换机，路由键设为"p2p.接收方用户ID"，消息只会进入对应用户的私人队列。
• 群聊广播：用Fanout交换机，消息发到交换机后，复制给所有绑定的队列，每个群成员一个队列都能收到。
• 定向通知：用Topic交换机，路由键支持通配符匹配，比如"group.123.*"，可以精准匹配某个群的所有类型的通知。

这种路由模型的灵活性，在业务需求经常变化的IM系统里非常实用。比如一个群聊功能，今天只让群公告进队列，明天可能想增加群投票消息、群文件消息，只需要调整路由键和队列绑定的规则即可，不需要重新设计基础架构。

2.4 状态广播：上下线、已读回执这类事件的分发

IM系统里除了消息本身，还有大量的"状态事件"：用户上线了、下线了、消息已读了、正在输入中、好友请求通过了。这些事件的特点是：数据量小、频率高、对实时性要求高、而且往往需要推给多个接收方。

如果用户A上线，他的所有好友都应该收到"A上线了"这个事件，而好友列表可能在用户关系服务里维护，好友连接在网关服务里维护。这时候一个直接的HTTP调用链会非常繁琐。用RabbitMQ广播则简单得多：网关服务检测到A上线，把事件发到"user-status"交换机，所有在线的网关实例都订阅了这个队列，各自检查自己的连接池里有没有A的好友，有就推送上线通知。这个过程各服务独立完成，互相不依赖。

3. 一条消息的完整旅程：从发送到接收的每一步都走一遍

理论讲再多，不如把一条消息走一遍全流程。我们用最简单的"用户A给用户B发一条私聊消息"作为例子，从接入网关开始，一步步拆解RabbitMQ在其中扮演的角色。

3.1 消息入口：网关收到消息之后做了什么

用户A通过WebSocket连接到了网关实例G1，发来一条聊天消息。网关G1不会直接去查B在哪里，它只做一件简单的事：把消息转成一个标准格式的事件，通过生产者客户端投递到RabbitMQ的交换机。

这一步我把消息设计的重点补充一下。投递到RabbitMQ的消息体一般包含三个部分：消息ID（全局唯一）、消息内容（JSON序列化）、路由信息（接收方ID、消息类型、群组ID等）。千万不要把整个业务对象塞进消息体，因为消费者可能只需要路由信息而不是完整内容，塞多了浪费网络带宽，也拖慢序列化速度。

伪代码大概是这样的：

java复制String msgId = UUID.randomUUID().toString();
MessagePayload payload = new MessagePayload();
payload.setMsgId(msgId);
payload.setFromUserId("A");
payload.setToUserId("B");
payload.setContent("你好，B");
payload.setType("text");

MessageProperties props = new MessageProperties();
props.setDeliveryMode(MessageDeliveryMode.PERSISTENT);
props.setMessageId(msgId);
// 路由键是 p2p.B，direct交换机
rabbitTemplate.convertAndSend("im.exchange.direct", "p2p.B", payload, props);

这块代码我们生产环境跑了很久，实际有个小坑：convertAndSend 使用默认的Java序列化器时，消息体会带很多Java类信息，非常臃肿。建议统一配置为JSON序列化器，可以大幅减小消息体体积，也方便其他语言的服务消费。

3.2 交换机与队列绑定：消息如何找到正确的队列

网关G1把消息发到交换机"im.exchange.direct"，路由键是"p2p.B"。接下来就要看交换机上的绑定了。在RabbitMQ里，一个交换机和队列绑定的时候会指定一个绑定键（BindingKey）。Direct交换机的路由逻辑是：如果消息的路由键和某个队列的绑定键完全一致，这个消息就进入那个队列。

所以我们在创建B的私聊队列时，会把队列"im.queue.user.B"绑定到"im.exchange.direct"，绑定键设为"p2p.B"。这样消息一进交换机，就直接落到B的私聊队列。

关于队列的创建方式，开发环境里我习惯用代码自动声明（@Bean 声明Queue、Exchange、Binding），方便一键启动；但生产环境强烈建议由运维或DBA在RabbitMQ管理后台统一创建队列和绑定，并且把队列设置为持久化，避免消费者还没启动前消息就已经丢失的问题。代码里动态创建队列虽然方便，但一旦队列设计不合理，后面很难清理。我见过一个团队在代码里用UUID生成队列名，一天下来RabbitMQ里多了几万个临时队列，后台管理直接卡成PPT，这个案例不是段子。

3.3 消息存储与路由：消费端处理的主战场

B的私聊队列里有了消息，谁来消费？在IM架构里，负责消费这条消息的通常是消息服务。它从队列里拉取消息，做这几件事：

• 根据msgId做幂等校验，防止重复消息
• 把消息内容写入数据库（或Redis）做持久化
• 更新A和B的会话列表、未读数
• 触发"消息需推送"的后续操作

这里要特别注意：消费完了需要手动确认（ACK），RabbitMQ收到ACK之后才会把这条消息从队列中删除。如果消费者的业务逻辑处理到一半抛异常了，这条消息会被重新投递，这叫重试。重试机制我在后面可靠性部分细讲。

3.4 消息推送：在线状态如何贯通

消息服务把消息存好之后，还要让B收到。问题是，B连接在哪个网关实例上，消息服务并不知道。这里的做法是：消息服务把"需要推送的消息"再投递到一个推送交换机（比如"im.exchange.push"，Topic类型），路由键是"push.B"。所有网关实例，包括G1、G5、G10等等，都各自声明了一个队列绑定到这个交换机上，绑定键设为"push.*"——也就是说，每个网关实例都会收到这条推送消息。

每个网关实例收到推送消息后，检查自己的本地连接池里有没有B的连接：

• 如果有，说明B就挂在当前实例上，直接把消息推给B。
• 如果没有，当前实例什么事都不做，这条推送消息就被"丢弃"了。

这是IM系统里常见的一个设计模式叫"广播式投递"：每条消息广播给所有网关，只有持有目标连接的那个网关才会实际推送。这个方案的优点是网关实例完全无状态、不需要互相注册、天然支持扩缩容，缺点是有一定的消息冗余，但在在线用户规模没到百万级以上的时候，完全够用。

4. 可靠性设计：防止消息丢失、重复和堆积

消息队列使用中最怕的就是丢消息。即时通讯里的消息是不能丢的，用户发了消息结果对方永远收不到，投诉马上就来了。RabbitMQ的可靠性要从三个环节分别配置，缺一不可。

4.1 生产端：确保消息确实进了Broker

生产端（网关服务）把消息发给RabbitMQ，中间隔着网络，可能发生消息根本没到Broker就丢了的情况。解决这个问题需要开启Publisher Confirm机制。

java复制// 在连接工厂上开启
ConnectionFactory factory = new ConnectionFactory();
factory.setPublisherConfirmType(CachedConnectionFactory.PublisherConfirmType.CORRELATED);
factory.setPublisherReturns(true);

开启之后，生产者发送消息会得到一个确认回调。如果RabbitMQ成功接收并持久化了消息，会回调 confirm；如果交换机发现没有匹配的队列，会回调 returnedMessage。这两个回调一定要实现并记录日志，我们生产环境遇到过一次上游服务改路由键，导致消息无法路由，就是靠returnedMessage日志排查出来的。

Spring AMQP里，可以这样处理确认回调：

java复制rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> {
    if (!ack) {
        log.error("消息投递失败: {}, cause: {}", correlationData, cause);
        // 补偿：写入本地失败表，定时重发
    }
});

这里我要多提一句，很多团队生产端只用了confirm，但没有处理ack=false的情况，这等于白配。我踩过一次坑：某个接口改造后，调用了不存在的交换机，RabbitMQ直接返回了ack=false，但因为我没有处理这个分支，这条消息就静默丢失了，用户那边卡了一下午。所以请一定要把确认失败的分支当成正常逻辑来处理。

4.2 队列与消息持久化：防止RabbitMQ重启后消息全丢

消息进入到RabbitMQ的队列之后，如果RabbitMQ节点宕机重启了，没有持久化的消息就会全部消失。要让消息在Broker重启后不丢，需要同时满足三个条件，缺一个都不行：

• 队列声明为持久化（durable=true）
• 消息投递时设置 MessageDeliveryMode.PERSISTENT
• 至少有一个副本在磁盘上写入完成

第三个条件实际指的是RabbitMQ的惰性队列（lazy queue）或者镜像队列/仲裁队列的配置。常规队列在消息量大的时候，会先把消息放内存再异步刷盘，如果这个过程中节点宕机，内存里的消息会丢。2021年之后RabbitMQ官方重点推荐仲裁队列（quorum queue），它基于Raft协议，多节点复制，消息写入之后会同步到多个副本，持久化更稳。生产环境如果对不丢消息有硬性要求，建议直接用仲裁队列。

需要注意的是，仲裁队列和镜像队列不能混用，它的消息顺序性保证和消费方式也和普通队列略有不同。我最初把旧代码从经典队列切到仲裁队列时，遇到消费者报了一个奇怪的异常，排查了半天才发现是经典队列里一个隐式的自动删除行为在仲裁队列里不存在，代码里没有显式处理，所以如果你要切队列类型，一定要回归测试。

4.3 消费端：手动ACK、重试机制和死信

消息进入到消费者手里，消费者处理成功了，RabbitMQ才会认为这条消息已经被消费。如果消费者处理失败，我们通常要做两件事：重试、进入死信。

手动ACK的基本配置：

java复制@RabbitListener(queues = "im.queue.user.B", ackMode = "MANUAL")
public void onMessage(Message message, Channel channel) {
    long deliveryTag = message.getMessageProperties().getDeliveryTag();
    try {
        // 业务处理：存库、幂等校验、推送
        channel.basicAck(deliveryTag, false);
    } catch (Exception e) {
        // 业务处理失败，不确认，让消息重回队列
        channel.basicNack(deliveryTag, false, true);
    }
}

这里有一个非常常见的坑：basicNack 的第三个参数 requeue 如果设为true，消息会重新放回队列头部，然后立即被同一个消费者再次取走，形成无限循环。如果业务逻辑是"处理失败就重试"，但失败的代码逻辑有bug，那么这条消息就会在这个消费者上疯狂打转，CPU飙高、日志刷屏，整个服务都受影响。

我的建议是：重试机制不要放在RabbitMQ层面，而是放在业务代码里。第一次消费失败后，把消息状态标记为"重试中"，扔到一个延迟处理的任务表里，隔几秒、几十秒、几分钟做有梯度的重试，超过最大重试次数就进入死信队列，人工介入处理。这样既不会无限循环，也能保证不丢消息。

4.4 死信队列：处理不可消费的消息

死信队列的核心价值在于：把消费失败的消息从一个"反复折磨消费者的队列"转移到一个专门的队列，供开发人员查看、重新处理。在IM场景里，死信队列的典型用途有两个：

• 超过重试次数的推送任务：比如某个用户设备注册信息失效，推送一直失败，超过一定次数后进入死信队列，运营同学可以定期处理。
• 延迟消息（通过死信+TTL实现）：比如用户发消息后对方N分钟未读，要给发送方回执"消息未读"，这种延迟任务可以巧妙暗用死信队列机制来实现——先把消息发到普通的TTL队列，过期后自动进入死信队列，由真正消费延迟任务的消费者处理。

死信队列的配置是在普通队列上设置参数：

java复制@Bean
public Queue imQueue() {
    Map<String, Object> args = new HashMap<>();
    args.put("x-dead-letter-exchange", "im.exchange.dlx");
    args.put("x-dead-letter-routing-key", "im.dlx.user.B");
    return new Queue("im.queue.user.B", true, false, false, args);
}

这里有个经验，死信队列一定要加监控，而且告警阈值要调低。死信队列里只要有消息，就说明有业务处理失败了，理论上应该为0。很多团队死信队列积压了几十万条消息也没人注意，直到某天用户投诉"我昨天的消息没收到"，一查才发现全在死信里躺着，这种教训我见过太多次。

5. 中间件选型：为什么是RabbitMQ而不是Kafka或RocketMQ

写完核心功能之后，很多朋友会问：Kafka现在这么火，为什么不直接用Kafka做IM？我理解大家有这个疑问，但消息中间件选型从来没有"最牛"的，只有"最合适"的，得看场景。

5.1 排除Kafka的理由：消息模型不匹配

Kafka的消息模型是"分区日志"，适合的场景是大规模日志采集、流式计算、事件溯源，它追求的是超高的吞吐量。但它有两个特点在IM场景里是痛点：

• 路由能力弱。Kafka只有Topic一个维度，没有RabbitMQ那种Exchange+RoutingKey+Queue的组合路由能力。一个群聊场景，RabbitMQ可以通过Topic交换机配合通配符精确匹配，而Kafka需要自行管理消费者与分区的对应关系，业务代码会复杂很多。
• 消息堆积期间的位置管理。Kafka的消费者只能从分区的某个offset开始读，不方便针对"某个用户的消息"做灵活的消息级处理。

5.2 排除RocketMQ的理由：维护成本偏高

RocketMQ在可靠性、事务消息、延迟消息方面做得很好，延迟消息调度在RocketMQ里是开箱即用的，比RabbitMQ的死信+TTL方案优雅不少。但在中小团队里，它的部署和运维成本比RabbitMQ高，管理控制台、Broker的NameServer、多副本同步等一整套体系，必须有专人维护。RabbitMQ的生态则成熟得多，Erlang实现的单节点性能足够应对大多数IM系统需求，有很直观的HTTP管理界面，对中小团队更友好。

所以我的结论很直接：如果项目已经采用Spring Boot/Spring Cloud这套微服务生态，团队没有专业的中间件运维专家，消息的消费模型是"按用户、按群组做精准投递"，那RabbitMQ是性价比非常高的选择。只有当你确认未来会有海量日志和事件流处理需求时，才值得考虑Kafka。RocketMQ则更适合那种追求极端可靠性和事务消息、且有专人运维的团队。

这里我多说一句，选型这件事不是写PPT，一定要拿业务场景去压测。我们当时实际做了一轮模拟测试：1个群里有1000个成员，消息服务同时往RabbitMQ里投递1000条消息，看RabbitMQ的处理延迟和消费者吞吐，结论是完全没有压力。又测了全系统广播10万在线用户的场景，持久化+多消费者并行消费，峰值延迟在可接受范围内，这才敲定下来。

6. 生产环境落地：连接管理、配置优化与踩坑记录

最后这部分，把我实际部署和生产运行中积累的实战经验分享出来。这些内容在官方文档里不会写得很细，但都是能救人一命的东西。

6.1 Connection与Channel：一个服务只维护一个长连接

RabbitMQ的性能瓶颈很多时候不是Broker，而是客户端连接管理方式不对。RabbitMQ官方建议：每个应用进程只需要维护一个Connection，但可以创建多个Channel。因为一个Connection底层就是一条TCP长连接，创建和销毁都很重，而Channel是轻量级的虚拟连接，创建销毁成本极低。

在Spring AMQP里，CachingConnectionFactory 默认就会做连接复用，但要注意channelCacheSize的配置。如果项目里有大量并发消息投递，建议把缓存调大些：

code复制spring.rabbitmq.cache.channel.size=50
spring.rabbitmq.cache.connection.mode=CONNECTION

我们遇到过一个问题：某个线上环境默认的channel缓存只有10，但业务高峰期每个消息处理器都要占用一个channel，导致大量线程在等待channel资源，最终影响了投递延迟。调大之后立竿见影。

6.2 消息体大小与序列化方案

RabbitMQ不是一个适合传大消息的中间件，官方推荐的单条消息上限大概是128MB，但实际生产环境建议把所有消息体控制在KB级别。太大的消息会拖慢整个Broker的处理速度，也会让磁盘I/O压力大增。如果业务上确实需要传图片、文件的消息，应该只把文件URL放进消息体，文件本身放到对象存储。

序列化方案上，统一用JSON。Java默认的JDK序列化生成的消息体不仅体积大，而且无法被其他语言写成的消费者反序列化。如果后续有跨语言需求（比如用Go写一个消费者做数据统计），JSON是最稳妥的选择。需要注意，使用JSON序列化时，消息体里不要携带复杂的循环引用对象，否则序列化性能会急剧下降。

6.3 监控与告警：看这几个指标就够了

RabbitMQ管理后台的功能很多，但真正需要每天关注的指标就那几个：

管理后台的HTTP接口可以接入Prometheus这类监控系统里。如果只是小规模使用，写个定时脚本抓取管理API也能实现最基础的监控。重点要盯死信队列和Ready消息数，这两项不盯，出事的时候往往是用户先投诉，你才知道消息卡住了。

6.4 幂等消费：消息重复是常态

RabbitMQ的可靠性机制有个副作用：消息可能被重复投递。比如消费者处理完业务逻辑，还没来得及发送ACK，进程就崩溃了，RabbitMQ会重新把这条消息投递给另一个消费者，于是这条消息被处理了两次。在IM场景里，消息重复可能导致两个严重后果：消息数据库中产生重复记录、未读数被多加了一次。

解决幂等最通用的方案是：每个消息都带一个全局唯一的msgId，消费端在业务处理之前，先查一下这个msgId是否已经处理过。在我们的项目里，用的是Redis的SETNX命令，消息处理前执行 SET msgId 1 NX EX 86400，如果返回成功，说明是第一次处理，继续执行；如果返回失败，说明已经处理过，直接ACK并丢弃。

这里有个容易忽略的点：幂等校验一定要和业务处理放到同一个事务里，否则会出现"幂等校验通过了，但业务处理失败回滚，消息又被重新投递"的情况。最简单的方法是先把msgId写进一个处理中表，业务处理完成后再把状态改为已完成；或者用本地消息表+幂等约束，确保绝对不重复。

6.5 集群部署：最少三个节点

如果是生产环境，RabbitMQ不要单节点部署，否则Broker宕机就是单点故障。最好搭一个三节点集群，用仲裁队列做多副本复制。节点之间用局域网连接，延迟很低，仲裁队列的性能在正常IM消息量下完全够用。

集群部署的另一个好处是管理端高可用。我之前有一个项目在Docker里单节点跑RabbitMQ，有一次宿主机重启，RabbitMQ容器虽然自动起来了，但那期间所有消息都丢了，后来就再不敢单节点了。既然都上微服务了，这种基础中间件的冗余配置不能省。

最后说两个我亲测有效的小技巧

第一，RabbitMQ配合延时队列做IM里的"消息撤回"很顺手。用户A发了一条消息给B，B还没看，A想把消息撤回。如果撤回请求只是简单更新数据库状态，B的客户端可能还保留着原始消息。我们的做法是把撤回操作设计成一条延迟消息：撤回请求先进入一个TTL为10秒的队列，10秒之后进入死信队列，由消费者把这个撤回事件推送到B的客户端。这个10秒的窗口保证了撤回只对未读消息有效，已读消息就不允许撤回了。

第二，不同环境的交换机要用不同的命名前缀。开发环境、测试环境、生产环境用一套RabbitMQ集群（虽然不建议，但小公司常这么干）时，队列和交换机一定要加环境前缀，比如dev.im.queue.user.B、prod.im.queue.user.B，否则会互相干扰，消费方可能把开发环境的测试消息当成线上消息处理掉，引起线上事故。

微服务架构里的即时通讯，本质就是一场异步化改造。把同步的、阻塞的、容易超时的调用，改造成异步的、消息驱动的、抗压力的环形链路，而RabbitMQ就是这条链路上最核心的枢纽。把这篇文章里的设计和配置吃透，你做的IM系统在可靠性上已经超过大多数团队了。