RabbitMQ七种消息模型解析：从简单队列到发布确认的实践指南

RabbitMQ 这玩意儿，我第一次接触是在一个订单系统里。当时项目已经上线了，突然有一天运营反馈说用户收到了重复的通知短信，一查日志发现生产者把消息发到了默认交换机，消费者那边又是自动确认，一重启服务消息就重新入队，再加上接口超时重试，一来二去就乱套了。那时候我才意识到，RabbitMQ 的文档虽然写得清楚，但真正要落地，靠的是把七种消息模型的边界搞清楚。

这篇东西我整理了挺久，从最基础的 Simple 模式一路写到工作队列、发布/订阅、路由、通配符、RPC 和发布确认机制，每条都配了原生 Java 客户端的可运行代码，也补充了平时生产环境里最容易被忽略的细节。适合刚把 RabbitMQ 环境跑起来、开始接触消息模型的初学者，也适合已经用过一阵子但想把模型选型逻辑彻底理清的同学参考。

1. 动手之前的必修课：Exchange、Queue、Binding 到底怎么协作

1.1 先把环境跑起来

不管你是 Windows 还是 macOS，我都不建议直接去官网下载安装包折腾 Erlang 和 RabbitMQ 的版本匹配问题。最省事的方式是用 Docker，一条命令就能把带管理界面的服务拉起来：

bash复制docker run -d --name rabbitmq \
  -p 5672:5672 -p 15672:15672 \
  -e RABBITMQ_DEFAULT_USER=admin \
  -e RABBITMQ_DEFAULT_PASS=admin123 \
  rabbitmq:3-management

5672 是 AMQP 协议端口，15672 是管理界面端口。如果你已经在用 Windows 原生方式部署，记得装完 RabbitMQ 之后手动开一下管理插件：

bash复制rabbitmq-plugins enable rabbitmq_management

默认账号 guest 只能从 localhost 访问，远程连管理界面或者代码连非本机地址，都需要自己建用户、配权限。这个坑我见过不少人踩，代码里连接报错 first login 失败，其实就是 guest 的访问限制闹的。

管理界面启动之后，http://localhost:15672 就能看到队列、交换机、绑定关系以及消息的实时流量。我强烈建议你在跑下面每个模式的时候，都打开 Exchange 和 Queues 两个标签页，肉眼看一遍消息是怎么流转的。这个习惯比看十篇文档都管用。

1.2 消息不是直接进队列的

RabbitMQ 最核心、也最容易被初学者忽略的设计是：生产者不直接把消息丢进队列，而是先发给交换机（Exchange），由交换机根据绑定关系（Binding）把消息路由到一个或多个队列。

你可以把交换机理解成快递中转站。快递员（生产者）只负责把包裹送到中转站，至于包裹最终是送到 A 小区还是 B 小区，取决于中转站的分拣规则（交换机类型 + 路由键）。如果中转站发现没有匹配的收货地址，包裹要么被退回（Return 回调），要么被悄悄丢弃——这取决于你发布消息时的 mandatory 参数。

对应到代码里有三个必须理解的概念：

• Exchange：接收生产者消息的入口，有 direct、fanout、topic、headers 四种类型。
• Queue：真正存储消息的地方，消费者从这里拉消息。
• Binding：把 Exchange 和 Queue 连起来的"分拣规则"，绑定的时候要指定 BindingKey。

生产者发送消息时携带一个 RoutingKey，交换机拿着这个 RoutingKey 和所有队列的 BindingKey 做匹配，匹配上了就投递。这里最容易被绕晕的地方是 RoutingKey 和 BindingKey 的关系——除了 fanout 交换机不关心键值之外，rest 模式下两者配合决定了消息的去向。

1.3 RoutingKey 和 BindingKey 的约定与误会

我刚学的时候一直分不清 RoutingKey 和 BindingKey 是不是同一个东西。后来在实践中总结出一个朴素的记忆方式：

• 生产者视角叫 RoutingKey，是消息自带的"门牌号"。
• 消费者视角叫 BindingKey，是队列和交换机绑定时登记的"期望门牌号"。
• 两者匹配成功，消息就进队列；匹配失败，消息就流浪。

但这个说法只在 direct 交换机下最精确。到了 topic 交换机，BindingKey 变成带通配符的表达式，比如 order.* 能匹配 order.create 也能匹配 order.cancel，但匹配不了 order.create.success。到了 fanout 交换机，门牌号直接被无视，消息复制给所有绑定的队列。

所以在看任何一篇讲 RabbitMQ 模式的文章之前，先把 Exchange、Queue、Binding 三者的关系在脑子里转一遍，后面所有模式就都是"换不同的交换机类型 + 不同的绑定规则"而已。

2. Simple 模式和工作队列：从单机通知到并行消费

2.1 Simple 模式：最朴素的队列模型

Simple 模式是最基础的模型，一个生产者、一个队列、一个消费者。生产端代码如下：

java复制ConnectionFactory factory = new ConnectionFactory();
factory.setHost("localhost");
factory.setUsername("admin");
factory.setPassword("admin123");

try (Connection connection = factory.newConnection();
     Channel channel = connection.createChannel()) {
    // 声明队列：durable=true 表示队列持久化，重启不丢
    channel.queueDeclare("simple_queue", true, false, false, null);

    String message = "订单创建成功";
    channel.basicPublish("", "simple_queue",
            MessageProperties.PERSISTENT_TEXT_PLAIN,
            message.getBytes(StandardCharsets.UTF_8));
    System.out.println(" [x] Sent '" + message + "'");
}

注意生产者的 basicPublish 第一个参数传的是空字符串，这表示使用默认交换机。默认交换机是 direct 类型，它的特殊之处在于每个队列都会隐式绑定额外一个和队列同名的 BindingKey，所以你把 routingKey 写成队列名 "simple_queue"，消息就能准确进队。

消费端代码同样简单：

java复制ConnectionFactory factory = new ConnectionFactory();
factory.setHost("localhost");

Connection connection = factory.newConnection();
Channel channel = connection.createChannel();
channel.queueDeclare("simple_queue", true, false, false, null);

DeliverCallback deliverCallback = (consumerTag, delivery) -> {
    String message = new String(delivery.getBody(), StandardCharsets.UTF_8);
    System.out.println(" [x] Received '" + message + "'");
    // 手动确认，告诉 RabbitMQ 这条消息我已经处理完了
    channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
};

// 第二个参数 autoAck=false，关闭自动确认
channel.basicConsume("simple_queue", false, deliverCallback, consumerTag -> {});

这里有个非常关键的细节：basicConsume 的第二个参数我传的 false。如果传 true，消费者一收到消息就自动回 ACK，不管业务里后面是不是抛异常了。一旦业务处理失败，消息已经被标记为已消费，等于静默丢失。这是 Simple 模式变成"事故模式"最常见的原因。

2.2 工作队列的公平分发：prefetch 的前世今生

把 Simple 模式里的消费者再复制一份出来，让两个消费者监听同一个队列，就成了工作队列（Work Queue）模式。它的作用是削峰和并行处理，比如批量发送邮件、导出报表这种耗时任务，单消费者处理不过来，就起多个消费者分摊。

工作队列默认的分发方式是轮询（round-robin），RabbitMQ 按顺序把消息一条一条轮流发给各个消费者。这样看似公平，实际上有隐患：如果两条消息的处理耗时差异很大，比如一条只要 10 毫秒，另一条要 10 秒，轮询模式下处理快的消费者可能有一半时间在空等，处理慢的消费者堆积越来越多。

解决办法是设置预取计数，让消费者一次最多拿一条消息，处理完并且 ACK 之后再拿下一条：

java复制// 放在 basicConsume 之前
channel.basicQos(1);

basicQos(1) 是公平分发的核心。设置之后，RabbitMQ 只会给消费者发送 1 条未确认的消息，消费者处理完并发送 ACK，才会收到下一条。这样处理快的消费者自然能消费更多消息，实现"能者多劳"。

注意，basicQos 生效的前提必须是手动 ACK。如果你用的是自动确认，RabbitMQ 认为消息发出去就已经处理完了，根本不会管你是否忙得过来，prefetch 形同虚设。

2.3 消息确认从自动到手动带来的变化

把 ACK 改成手动之后，你需要重新审视消费者的代码结构。我见过很多新手直接在回调里写业务逻辑，然后无脑 ack，结果数据库事务回滚了、消息却已经确认了。正确姿势是：

java复制DeliverCallback deliverCallback = (consumerTag, delivery) -> {
    long deliveryTag = delivery.getEnvelope().getDeliveryTag();
    try {
        // 1. 解析消息
        // 2. 处理业务（操作数据库、调用接口等）
        // 3. 业务成功后才确认
        channel.basicAck(deliveryTag, false);
    } catch (Exception e) {
        // 处理失败，第二个参数 requeue=true 表示重新放回队列
        // 如果场景不适合无限重试，可以 false 并配合死信队列
        channel.basicNack(deliveryTag, false, true);
        log.error("消息处理失败", e);
    }
};

这里 basicNack 的第三个参数 requeue 要特别小心。true 会把消息重新放回原队列，如果消费端代码有 bug，会导致同一消息被反复投递，形成无限循环，堆积越来越多。生产上更稳妥的做法是：重试几次仍然失败后，把消息投递到死信队列，或者记录日志后手动补偿。

3. 三种交换机模式：发布/订阅、路由、通配符到底怎么选

3.1 fanout：广播出去，谁绑谁收

发布/订阅模式用的是 fanout 交换机。它的特点是完全忽略 RoutingKey，只要队列和该交换机绑定了，消息就会被复制发送给所有绑定的队列，每个队列的消费者都能收到一份完整消息。

适合的场景是"一个事件需要广播给多个下游系统"。比如订单状态变化后，库存系统要减库存、积分系统要加积分、物流系统要创建运单，这三个系统互相不关心对方是否处理成功，但都必须收到订单状态变更的通知。

生产者代码：

java复制channel.exchangeDeclare("order_fanout", BuiltinExchangeType.FANOUT);

String message = "订单状态变更为已支付";
channel.basicPublish("order_fanout", "", null,
        message.getBytes(StandardCharsets.UTF_8));
// 注意 fanout 模式下 routingKey 传空字符串即可，传什么都会被忽略

消费者绑定：

java复制channel.exchangeDeclare("order_fanout", BuiltinExchangeType.FANOUT);
String queueName = channel.queueDeclare().getQueue();
// 临时队列：连接断开自动删除，适合不需要持久化的场景
channel.queueBind(queueName, "order_fanout", "");

DeliverCallback deliverCallback = (consumerTag, delivery) -> {
    String message = new String(delivery.getBody(), StandardCharsets.UTF_8);
    System.out.println(" [x] 库存系统收到: " + message);
};
channel.basicConsume(queueName, true, deliverCallback, consumerTag -> {});

用小技巧理解 fanout：它就是个广播喇叭，至于谁在听、听几遍，它完全不管。只要队列绑定了交换机，来消息就有份。

3.2 direct：路由键的精确匹配

如果广播不能满足需求——比如日志系统里，错误日志要发给告警服务，普通日志只进存储——就需要用 direct 交换机。direct 交换机根据 RoutingKey 和 BindingKey 的精确匹配来路由消息。

生产者发送消息时指定 RoutingKey，交换机只把消息投递给 BindingKey 完全一致的队列。

java复制channel.exchangeDeclare("log_direct", BuiltinExchangeType.DIRECT);
channel.queueDeclare("error_queue", true, false, false, null);
channel.queueBind("error_queue", "log_direct", "error");
channel.queueDeclare("info_queue", true, false, false, null);
channel.queueBind("info_queue", "log_direct", "info");

// 发送 error 级别日志，只会进入 error_queue
channel.basicPublish("log_direct", "error", null,
        "数据库连接失败".getBytes(StandardCharsets.UTF_8));

direct 模式理解起来很直观，但如果 RoutingKey 的命名没有统一规范，很快就乱成一团。我实际项目里的经验是：RoutingKey 一定要用一套枚举常量统一维护，禁止在业务代码里手写字符串，否则换个产品经理就能把消息路由搞得乱七八糟。

3.3 topic：用 * 和 # 做模糊路由

通配符模式（topic）是三种交换机模式里表达能力最强的。它的 RoutingKey 用 . 分割成若干个词，BindingKey 支持两个通配符：

• *：匹配一个词
• #：匹配零个或多个词

举个例子。假设 RoutingKey 格式是 服务名.日志级别：

生产者代码：

java复制channel.exchangeDeclare("log_topic", BuiltinExchangeType.TOPIC);
channel.queueBind("order_error_queue", "log_topic", "order.error");
channel.queueBind("all_log_queue", "log_topic", "#");

// 投递到 order.error，匹配 order_error_queue
channel.basicPublish("log_topic", "order.error", null,
        "订单服务出现异常".getBytes(StandardCharsets.UTF_8));

// 投递到 pay.info，匹配 all_log_queue
channel.basicPublish("log_topic", "pay.info", null,
        "支付回调成功".getBytes(StandardCharsets.UTF_8));

topic 模式最大的价值在于，你可以通过设计一套语义清晰的 RoutingKey 规则，灵活地实现各种订阅粒度。比如上面对比表里的 *.error 就能一次订阅所有服务的错误日志，这在排查分布式系统问题的时候特别好用。

3.4 三种交换机选型实战对照

我在面对实际业务时一般用这张表做判断：

headers 交换机我基本没用过，它根据消息携带的 headers 键值对做匹配，灵活性很高但可维护性太差，实际项目里用 topic 基本都能替代，所以本文不展开。

选型时记住一个原则：先从简单的开始，能满足需求就尽量不用复杂的。只有 fanout 满足不了"某些消费者只关心部分消息"时，才升级到 direct；只有 direct 的精确匹配导致绑定关系爆炸、难以维护时，才升级到 topic。过度设计是最常见的坑。

4. RPC 模式：用两个队列模拟一次同步调用

4.1 replyTo 和 correlationId 两个核心参数

RPC 模式是 RabbitMQ 七种模式里最特殊的一个。RabbitMQ 本身是异步消息代理，但有些场景下你确实需要"发一条请求然后同步等待结果"，比如订单服务需要查库存服务的实时库存数量，又不想额外引入一套 RPC 框架。此时可以用两个队列模拟同步调用，思路是这样的：

1. 客户端（请求方）发送消息到服务端队列，消息里带上两个特殊属性：
   • replyTo：客户端自己的临时回调队列名，服务端处理完结果后把响应发到这个队列。
   • correlationId：本次请求的唯一标识，客户端用来把响应和请求关联起来。
2. 服务端（消费方）监听请求队列，处理完业务后，把结果发布到 replyTo 指定的队列。
3. 客户端在回调队列上等待，发现 correlationId 匹配就取出结果。

这里 correlationId 的设计有个很巧妙的点：多个客户端请求可以共用一个回调队列，靠 correlationId 区分响应属于哪个请求。如果不加这个字段，两个并发请求的响应就会张冠李戴。

4.2 服务端与客户端完整代码示例

先看服务端，它和普通消费者没有本质区别，只是处理完业务后多了一次"回发消息"：

java复制Channel channel = connection.createChannel();
channel.queueDeclare("rpc_queue", true, false, false, null);
// 同一时刻最多处理 1 个请求，避免并发把回调搞混
channel.basicQos(1);

DeliverCallback deliverCallback = (consumerTag, delivery) -> {
    // 取出请求方设置的 correlationId，回发响应时必须带上
    String correlationId = delivery.getProperties().getCorrelationId();
    String replyTo = delivery.getProperties().getReplyTo();

    AMQP.BasicProperties replyProps = new AMQP.BasicProperties.Builder()
            .correlationId(correlationId)
            .build();

    String request = new String(delivery.getBody(), StandardCharsets.UTF_8);
    String response = handleRequest(request); // 业务处理方法

    channel.basicPublish("", replyTo, replyProps,
            response.getBytes(StandardCharsets.UTF_8));
    channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
};

channel.basicConsume("rpc_queue", false, deliverCallback, consumerTag -> {});

客户端稍微复杂一点，关键在等待响应的方式。一般用 BlockingQueue 按 correlationId 维度等待，而不是用全局变量：

java复制Channel channel = connection.createChannel();
String replyQueueName = channel.queueDeclare().getQueue();
String correlationId = UUID.randomUUID().toString();

AMQP.BasicProperties props = new AMQP.BasicProperties.Builder()
        .correlationId(correlationId)
        .replyTo(replyQueueName)
        .build();

String message = "查询订单库存";
channel.basicPublish("", "rpc_queue", props, message.getBytes(StandardCharsets.UTF_8));

BlockingQueue<String> responseQueue = new ArrayBlockingQueue<>(1);
channel.basicConsume(replyQueueName, true, (consumerTag, delivery) -> {
    if (delivery.getProperties().getCorrelationId().equals(correlationId)) {
        responseQueue.offer(new String(delivery.getBody(), StandardCharsets.UTF_8));
    }
}, consumerTag -> {});

// 最多等 10 秒，超时直接放弃
String response = responseQueue.poll(10, TimeUnit.SECONDS);

这段代码里有个细节值得强调：回调方法里判断 correlationId 相等才放入队列，因为回调队列可能同时收到多个请求的响应，不匹配的直接忽略。另外，poll(10, TimeUnit.SECONDS) 这个超时必须有。我见过不写超时的线上事故，服务端挂了一半，客户端全部阻塞在 take() 上，线程池直接被耗尽。

4.3 RPC 模式什么时候值得用

说实话，现在微服务架构下跨服务同步调用首选还是专门的 RPC 框架，比如 Dubbo 或者 gRPC，它们在性能、负载均衡、熔断方面都做得更好。RabbitMQ RPC 模式真正的价值是在两类场景下：

• 跨语言、跨技术栈互调：只要两端都能识别 AMQP 协议，就能实现同步调用，不需要各自维护一套 SDK。
• 不想引入额外中间件：项目里已经有 RabbitMQ，只是偶尔需要几个同步查询接口，不值得再部署一套 RPC 服务。

使用 RPC 模式有个性能瓶颈要知道：每个请求都要走「发消息 -> 服务端处理 -> 回发消息 -> 客户端解析」这个完整链路，吞吐量远低于普通 RPC，所以接口并发一旦上来，队列很容易堆积。如果业务上允许，尽量把它改造成异步消息模式，或者把实时查询改成定时刷新缓存。

5. 发布确认机制：让每条消息都有回执

5.1 消息在三个环节都有丢失风险

很多初学者以为消息进了 RabbitMQ 就万无一失，其实消息丢失可能发生在三个环节：

• 生产者发送阶段：网络异常，消息根本没到交换机。
• 交换机路由阶段：交换机找不到匹配的队列，消息直接被丢弃。
• 消费者处理阶段：消费者收到消息后业务异常，但已经自动确认。

对应这三个环节，官方给出了不同的解决方案：

• 生产者端开启发布确认（Publisher Confirm），确认消息被成功写入队列。
• 发布消息时开启 mandatory 参数，配合 Return 回调感知路由失败。
• 消费者端关闭自动确认，改为手动 ACK，并配合死信队列处理失败消息。

三者配合起来，才能在绝大多数场景下保证"消息不丢"。但要注意，这不代表"消息不重复"，幂等性依然要靠消费端自己保证。

5.2 生产者确认的三种姿势

开启发布确认只需一行：

java复制channel.confirmSelect();

之后发送消息，RabbitMQ 会给这条消息分配一个自增的 deliveryTag，处理完成后通过回调通知生产者。根据确认方式不同，有三种常见姿势。

同步单条确认：每发一条就调用 waitForConfirms，等 RabbitMQ 确认之后再发下一条。代码简单，但吞吐量低，因为一条一条地等确认。

java复制channel.confirmSelect();
channel.basicPublish("", "confirm_queue", null, "msg".getBytes(StandardCharsets.UTF_8));
if (channel.waitForConfirms()) {
    System.out.println("发送成功");
}

同步批量确认：攒一批消息一起发，然后调用 waitForConfirmsOrDie，只要这一批里有一条未确认，就会抛 IOException，性能比单条高不少。缺点是如果批量中途失败，你很难定位具体是哪条消息出了问题。

java复制channel.confirmSelect();
for (int i = 0; i < 100; i++) {
    channel.basicPublish("", "confirm_queue", null, ("msg-" + i).getBytes(StandardCharsets.UTF_8));
}
channel.waitForConfirmsOrDie();
System.out.println("全部发送成功");

异步确认：注册 ConfirmListener 回调，RabbitMQ 确认成功后回调 handleAck，失败回调 handleNack。性能最好，适合高吞吐场景，但代码复杂度也最高，需要自己维护一个未确认消息的集合。回调里的 multiple 参数表示本次确认是否包含之前所有未确认的消息，一般配合游标批量移除。

java复制channel.confirmSelect();
ConcurrentSkipListMap<Long, String> outstanding = new ConcurrentSkipListMap<>();

channel.addConfirmListener((deliveryTag, multiple) -> {
    // 确认成功，从集合中移除
    if (multiple) {
        outstanding.headMap(deliveryTag + 1).clear();
    } else {
        outstanding.remove(deliveryTag);
    }
}, (deliveryTag, multiple) -> {
    // 确认失败，记录日志或补偿
    System.out.println("消息确认失败: " + deliveryTag);
});

outstanding.put(channel.getNextPublishSeqNo(), "msg-1");
channel.basicPublish("", "confirm_queue", null, "msg-1".getBytes(StandardCharsets.UTF_8));

生产环境我给的建议是：如果每秒就几千条消息，用同步批量确认足够了；如果量很大且不能接受批量失败，用异步确认。

另外，千万别用 RabbitMQ 的事务机制（txSelect/txCommit）来保证消息不丢。它每次发消息都要同步落盘并返回，性能差得离谱，官方都默认不推荐，我们有次压测对比，事务模式吞吐量只有发布确认模式的十分之一都不到。

5.3 消费者手动 ACK 与死信兜底

消费者端的可靠性设计，我在第 2 节提过手动 ACK 的代码，这里再补充一个进阶话题：死信队列。

所谓死信，就是"消息变成了无法正常消费的信件"。触发条件有三种：

• 消费者调用 basicNack 或 basicReject 且 requeue=false。
• 消息在队列里存活时间超过 TTL，过期了。
• 队列长度达到上限，新消息无法入队。

死信队列的原理是：给业务队列设置 x-dead-letter-exchange 和 x-dead-letter-routing-key，一旦消息变成死信，RabbitMQ 会自动把它转发到指定的死信交换机，再由死信交换机路由到死信队列。这样你就可以单独写一个消费者去处理这些"坏消息"，比如记录失败原因、做人工补偿或者隔一段时间重试。

声明死信队列的代码：

java复制Map<String, Object> args = new HashMap<>();
args.put("x-dead-letter-exchange", "dlx_exchange");
args.put("x-dead-letter-routing-key", "dead");

channel.exchangeDeclare("dlx_exchange", BuiltinExchangeType.DIRECT);
channel.queueDeclare("dlx_queue", true, false, false, null);
channel.queueBind("dlx_queue", "dlx_exchange", "dead");

// 业务队列绑定死信配置
channel.queueDeclare("business_queue", true, false, false, args);

消费者处理失败时：

java复制// 处理失败且不想重试，requeue=false 让消息进入死信队列
channel.basicNack(delivery.getEnvelope().getDeliveryTag(), false, false);

等死信队列里的消息攒到一定量，你可以开发一个补偿程序统一扫描、重新投递，也可以直接人工介入排查。总之，死信队列的价值在于：把"处理不了的消息"从主流程里隔离出来，既不影响正常消息的消费，又保留了问题追踪的入口。

6. 真实项目里的模式选型与踩坑清单

6.1 七种消息模型选型总览

把前面五节的内容浓缩成一张表，基本就是我在项目评审时参考的完整清单：

选型时还有两个容易忽略的纬度：消息要不要持久化，队列要不要持久化。队列的 durable=true 只代表队列本身重启后还在，不代表里面的消息还在。消息要持久化，就得在发布时设置 MessageProperties.PERSISTENT_TEXT_PLAIN，或者手动设置 deliveryMode=2。两者都配好，重启后消息才不丢。

6.2 我在生产环境踩过的几个坑

第一个坑是关于连接复用的。RabbitMQ 的 Connection 可以理解成一条 TCP 长连接，而 Channel 是这条连接上的轻量级子通道。初学者最容易犯的错误是每次都 new Connection，实际上 Connection 应该是全局单例，每个生产者/消费者线程再创建自己的 Channel。我见过有项目把连接工厂放到方法里，每发一条消息就新建连接，线上连接数直接打爆，RabbitMQ 拒绝新连接，服务大面积超时。

第二个坑是关于监听容器参数的。用 Spring Boot 集成 RabbitMQ 的同学，默认的 @RabbitListener 是单线程消费。如果业务里调第三方接口比较慢，而队列积压了几十万条消息，你需要主动调大并发度：

properties复制spring.rabbitmq.listener.simple.concurrency=5
spring.rabbitmq.listener.simple.max-concurrency=15
spring.rabbitmq.listener.simple.prefetch=1

注意 concurrency 不代表越多越好，它受限于数据库连接池、外部接口 QPS 等因素。要结合下游系统的承受能力压测，别一上来就开 50 个并发。

第三个坑是消息幂等。RabbitMQ 在发布确认 + 手动 ACK 的模式下，可能会出现"生产者发送成功后没收到确认，重试发送，结果消费者收到两条相同消息"的情况。这不是框架的 bug，而是分布式环境下的必然。消费者必须做幂等，推荐用业务消息里的唯一键，处理前先查一下数据库或者 Redis，已经处理过的直接返回成功。

第四个坑是消费者线程里的异常处理。在 DeliverCallback 里，如果 try-catch 不够细致，比如把 basicAck 放在 catch 外面，那么业务抛异常后 ack 不会执行，消息会一直被重投，日志却没有任何错误。最佳实践是：每个 DeliverCallback 里都要有 try-catch，ack 要放在 try 块内部，异常分支里记录日志并决定重投还是进死信。

6.3 关于集群和镜像队列的一句话建议

单机 RabbitMQ 虽然跑起来简单，但生产环境必须有高可用方案。最常用的是三节点镜像队列集群，让消息在多个节点上保存副本，发布确认会等待所有副本写入。搭建方式网上有很多 docker-compose 脚本，我这里只想强调一点：集群的节点规划要提前想清楚，三种节点类型（内存节点、磁盘节点、RAM 节点）的 mix 不能乱配，至少要有两个磁盘节点，否则集群重启时数据会丢。

如果你只是个人学习或者内部小项目，先用单机把本文的模式跑通即可。等真正上了生产、数据量起来，再考虑集群和镜像队列不迟。

说到底，RabbitMQ 的模式并不复杂，难的是在业务场景里做选择。我身边有些同事用了两三年 RabbitMQ，还是习惯用一个默认交换机写到头，连交换机类型都说不清。其实这套消息模型只要理清一次，后面换什么语言、换什么框架都是相通的。真要说有什么建议，我只会强调两条：一是先想清楚消息该不该丢、能不能重复，再决定开不开发布确认、要不要手动 ACK；二是把管理界面里的队列和绑定关系当调试工具用，肉眼看到消息从哪个交换机流到哪个队列，比看十篇文档都管用。