消息队列高级

玉米淀粉

已于 2025-03-06 23:05:32 修改

阅读量725

点赞数 11

分类专栏：消息队列面经文章标签： rabbitmq

于 2025-03-06 23:05:11 首次发布

本文链接：https://blog.youkuaiyun.com/weixin_54881347/article/details/146081871

版权

面经同时被 2 个专栏收录

6 篇文章

订阅专栏

消息队列

2 篇文章

订阅专栏

消息持久化与可靠性

消息队列的可靠性依赖于 消息持久化、确认机制（ACK） 和 重试策略 三者的协同设计。

一、消息持久化：防止数据丢失的基石

1. 什么是消息持久化？

将消息存储到 非易失性介质（如磁盘），即使系统崩溃或重启，消息仍可恢复。
关键目标：确保消息在传输过程中不丢失，尤其是在生产者到Broker、Broker到消费者的阶段。

2. 持久化实现方式

Broker（消息代理） 端持久化
- 写入磁盘：消息到达Broker后立即同步刷盘或异步刷盘。
  - 同步刷盘（如 RocketMQ SYNC_FLUSH）：消息写入内存后同步刷盘，数据零丢失，但吞吐量下降。
  - 异步刷盘（如 Kafka）：消息先写入 PageCache，由后台线程批量刷盘，性能高但可能丢数据。
- 副本机制：通过多副本（如 Kafka 的 ISR、RocketMQ 的主从复制）防止单点故障。
```
// RocketMQ 同步刷盘配置示例
brokerConfig.setFlushDiskType(FlushDiskType.SYNC_FLUSH);
```
队列/文件结构优化
- 顺序写入：Kafka 和 RocketMQ 将所有消息顺序追加到 CommitLog，避免随机 I/O。
- 分段存储：将大文件拆分为多个 Segment（如 Kafka 的 .log 文件），便于管理和快速恢复。
生产者端持久化
- 事务消息（如 RocketMQ）：通过二阶段提交确保本地事务与消息发送的原子性。
- 发送确认（如 RabbitMQ Publisher Confirms、Kafka ACKS=all）：生产者等待 Broker 确认消息已持久化。
```
// Kafka 生产者配置（要求所有副本确认）
props.put("acks", "all");
```

二、消息确认机制（ACK）：端到端的可靠性保障

1. 生产者确认（Producer ACK）

机制：生产者发送消息后，等待 Broker 返回确认信号。

级别：

Kafka：acks=0（无确认）、acks=1（Leader 确认）、acks=all（所有副本确认）。
RabbitMQ：Publisher Confirms（异步确认）或事务（性能差，不推荐）。

// RabbitMQ Confirm 模式
channel.confirmSelect(); // 开启 Confirm
channel.basicPublish("exchange", "routingKey", null, message.getBytes());
if (!channel.waitForConfirms(5000)) {
    // 消息未确认，触发重试
}

2. 消费者确认（Consumer ACK）

机制：消费者处理完成后通知 Broker，Broker 才删除消息。

模式：

自动 ACK（RabbitMQ autoAck=true）：消息推送给消费者后立即删除，风险高。
手动 ACK（推荐）：消费者显式发送 ACK/NACK，支持重试和死信队列。

// RabbitMQ 手动 ACK
channel.basicConsume(queue, false, (consumerTag, message) -> {
    try {
        process(message);
        channel.basicAck(message.getEnvelope().getDeliveryTag(), false);
    } catch (Exception e) {
        channel.basicNack(deliveryTag, false, true); // 重试
    }
});

3. 投递语义（Delivery Semantics）

最多一次（At-Most-Once）：可能丢失消息（如自动 ACK + 生产者不重试）。
至少一次（At-Least-Once）：消息不丢失但可能重复（手动 ACK + 生产者重试）。
精确一次（Exactly-Once）：需事务支持（如 Kafka 事务、RocketMQ 事务消息）。

三、重试策略：容错与最终一致性的关键

1. 生产者重试

场景：网络抖动、Broker 不可用导致发送失败。
策略：
- 指数退避重试：避免重试风暴（如首次 1s，后续 2s、4s、8s）。
- 最大重试次数：防止无限阻塞（如 3 次后记录日志或降级处理）。
```
// Kafka 生产者重试配置
props.put("retries", 3);
props.put("retry.backoff.ms", 1000);
```

2. 消费者重试

场景：消息处理失败（如依赖服务不可用、数据校验失败）。
策略：
- 本地重试：立即或延迟重试（如 RocketMQ 的 reconsumeTimes）。
- 死信队列（DLQ）：超过最大重试次数后转入死信队列，人工干预处理。
```
// RocketMQ 消费者重试（默认 16 次）
consumer.setMaxReconsumeTimes(3);
```

3. 消息去重（幂等性）

必要性：生产者重试和消费者重试可能导致重复消息。
实现：
- 唯一消息 ID：生产者生成唯一 ID，消费者通过数据库唯一索引去重。
- 幂等写入：如数据库 INSERT IGNORE 或 Redis SETNX 操作。
- 乐观锁：使用乐观锁（版本号）或条件更新。
- 去重表：维护已处理消息的记录表，处理前检查是否已存在。

四、典型消息队列实现对比

机制	RabbitMQ	Kafka	RocketMQ
持久化方式	队列和消息标记持久化 + 镜像队列	分区副本（ISR） + 异步刷盘	同步刷盘 + 主从同步复制
生产者确认	Publisher Confirms	ACKS=all	SYNC_MASTER + SYNC_FLUSH
消费者确认	手动 ACK/NACK	自动提交 Offset 或手动提交	自动重试 + 最大重试次数
重试策略	结合 NACK 和 DLQ	消费者自行管理 Offset 回滚	内置重试队列 + 死信队列
精确一次	需外部事务协调	支持（事务消息 + 幂等生产者）	支持（事务消息 + 去重表）

五、最佳实践：构建高可靠消息系统

配置建议
- 持久化级别：金融场景选择同步刷盘（RocketMQ）或 ACKS=all（Kafka）。
- 副本数量：至少 3 副本（如 Kafka replication.factor=3）。
监控与告警
- 关键指标：
  - 生产者：发送失败率、平均确认延迟。
  - 消费者：消息堆积量、重试次数、死信队列大小。
- 工具：Prometheus + Grafana、ELK 日志追踪。
容灾设计
- 跨机房部署：使用 RocketMQ 的 Dledger 或 Kafka MirrorMaker 实现异地复制。
- 备份与恢复：定期备份 Broker 数据（如 Kafka 的 Log 目录）。
代码层面
- 幂等处理：在消费者端对关键操作（如订单创建）设计去重逻辑。
- 异常捕获：消费者代码需捕获所有异常，避免因未 ACK 导致消息阻塞。

总结

消息队列的可靠性由 持久化、确认机制 和 重试策略 共同保障：

持久化确保消息在物理存储中不丢失。
ACK 机制控制消息从生产到消费的端到端生命周期。
重试策略处理临时故障，结合死信队列实现最终一致性。

实际应用中需根据业务需求（如吞吐量、延迟、数据一致性）权衡配置，并通过监控和容灾设计构建健壮的消息系统。

消息队列性能优化指南：瓶颈分析与配置技巧

消息队列的性能优化需从 生产者、Broker、消费者 三个层面入手，结合 高吞吐量 和 低延迟 的需求，针对性调整配置。以下是关键优化策略：

一、性能瓶颈分析

1. 常见瓶颈来源

生产者：网络带宽、序列化性能、批量发送策略不合理。
Broker：磁盘 I/O（持久化）、CPU（路由计算）、内存（缓存）、网络吞吐。
消费者：处理逻辑耗时、并发度不足、ACK 机制阻塞。
消息模型：顺序消息与并发消费的冲突、分区不均导致热点。

2. 性能指标监控

吞吐量：消息生产速率（msg/s）、消费速率（msg/s）。
延迟：端到端延迟（生产→消费）、Broker 处理延迟。
堆积量：未消费消息数（Consumer Lag）。
资源使用率：CPU、内存、磁盘 IOPS、网络带宽。

二、高吞吐量优化

1. 生产者优化

批量发送：增大单次发送的消息数量（Batch Size）。
- Kafka：batch.size=16384（16KB）、linger.ms=5（等待批量填满的时间）。
- RocketMQ：sendMsgTimeout=3000、compressMsgBodyOverHowmuch=4096（压缩阈值）。
压缩消息：使用 Snappy、LZ4 等算法减少网络传输量。
```
// Kafka 生产者配置
props.put("compression.type", "snappy");
```

异步发送：非阻塞发送，避免等待 Broker 响应。

// RocketMQ 异步发送示例
producer.send(msg, new SendCallback() {
    @Override public void onSuccess(SendResult result) { /* ... */ }
    @Override public void onException(Throwable e) { /* ... */ }
});

2. Broker 优化

磁盘顺序写：Kafka 和 RocketMQ 均采用顺序追加日志文件，避免随机 I/O。
PageCache 利用：依赖 OS 缓存加速读写（避免频繁刷盘）。
- Kafka：log.flush.interval.messages=10000（积累 1 万条消息后刷盘）。
分区/队列扩展：增加 Topic 的分区数（Kafka）或队列数（RocketMQ），提升并行度。
```
# Kafka 增加分区
kafka-topics.sh --alter --topic orders --partitions 8
```
集群负载均衡：确保分区均匀分布到所有 Broker 节点。

3. 消费者优化

提高并发度：消费者线程数 = 分区/队列数量。

// Kafka 消费者配置
props.put("max.poll.records", 500);  // 单次拉取最大消息数

批量拉取：增大单次拉取的消息数量。

异步处理：解耦消息拉取与业务处理，使用线程池并行消费。

// RocketMQ 并发消费（线程数=CPU 核心数×2）
consumer.setConsumeThreadMin(20);
consumer.setConsumeThreadMax(64);

三、低延迟优化

1. 生产者优化

减少批量等待：缩短批量发送的等待时间。
- Kafka：linger.ms=0（立即发送）。
禁用消息压缩：压缩会增加 CPU 开销（权衡带宽与延迟）。

2. Broker 优化

内存队列：RabbitMQ 使用内存存储非持久化消息（牺牲可靠性）。

// RabbitMQ 非持久化队列
channel.queueDeclare("cache_queue", false, false, false, null);

优化持久化策略：
- 同步刷盘改异步：RocketMQ flushDiskType=ASYNC_FLUSH。
- 调整刷盘间隔：Kafka log.flush.interval.ms=1000（1 秒刷盘一次）。

3. 消费者优化

减少处理耗时：优化业务逻辑（如异步写数据库、缓存预热）。
预取（Prefetch）调整：RabbitMQ 设置合理的预取数量，避免消费者空闲。
```
// RabbitMQ 预取配置（每次拉取 10 条）
channel.basicQos(10);
```
就近消费：消费者部署在靠近 Broker 的物理节点，减少网络延迟。

四、配置技巧对比

消息队列	高吞吐配置	低延迟配置
Kafka	`batch.size=64KB`, `linger.ms=5`, `acks=1`	`linger.ms=0`, `compression.type=none`
RabbitMQ	镜像队列 + 批量 ACK	内存队列 + 预取 1
RocketMQ	`useReentrantLock=false`, 异步刷盘	同步刷盘 + 消费线程池调优

五、场景化优化案例

1. 电商大促（高吞吐优先）

配置：
- Kafka：分区数=16，batch.size=128KB，Snappy 压缩。
- 消费者：多线程批量拉取，异步写入数据库。
效果：吞吐量提升 3 倍，容忍秒级延迟。

2. 实时风控（低延迟优先）

配置：
- RocketMQ：同步刷盘，消费者线程数=CPU 核数×2，禁用压缩。
- 业务逻辑：预加载风控规则到内存，实时计算。
效果：端到端延迟 < 50ms，TPS 稳定在 10 万。

六、高级调优工具

压力测试工具：
- Kafka：kafka-producer-perf-test.sh
- RabbitMQ：rabbitmq-perf-test
监控平台：
- Prometheus + Grafana（监控吞吐、延迟、堆积量）。
- Kafka Eagle、RocketMQ Dashboard（可视化集群状态）。
JVM 调优：
- 调整堆内存（如 Kafka KAFKA_HEAP_OPTS="-Xmx8G -Xms8G"）。
- GC 优化（G1 替代 CMS）。

总结

消息队列性能优化需围绕 吞吐量、延迟、可靠性 三角平衡，结合业务需求：

高吞吐：批量、压缩、异步、分区扩展。
低延迟：减少等待、内存队列、逻辑轻量化。
可靠性：同步刷盘、ACK 确认、副本机制。

通过监控数据定位瓶颈，逐步调整参数并验证效果，最终实现系统性能最优。

消息序列化：常见格式与实现方法分析

消息序列化是将数据结构或对象转换为可传输或存储的格式的过程，直接影响消息的传输效率、兼容性和系统性能。以下是主流序列化格式及其实现方法的深度解析：

一、常见消息序列化格式

格式	特点	适用场景
JSON	文本格式，可读性强，兼容性广，但体积较大。	REST API、Web 应用、日志记录
XML	标签式文本结构，扩展性强，冗余度高。	旧系统集成、配置文件
Protocol Buffers	二进制，高效紧凑，需预定义 `.proto` 模式，支持多语言。	微服务通信、高吞吐场景
Avro	二进制，自带 Schema，支持动态模式演化，适合大数据场景。	Hadoop、Kafka、跨语言数据交换
MessagePack	二进制，类似 JSON 结构，无模式定义，序列化速度极快。	实时通信、内存缓存
Thrift	二进制，需 IDL 定义，支持 RPC 和多语言。	跨语言服务调用（如 Facebook）
Bson	二进制 JSON 扩展，保留 JSON 结构但更高效。	MongoDB 存储、网络传输

二、序列化与反序列化实现方法

JSON（Jackson 库）

1. 添加 Maven 依赖

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.15.2</version>
</dependency>

2. 序列化与反序列化

import com.fasterxml.jackson.databind.ObjectMapper;

public class JsonExample {
    public static void main(String[] args) throws Exception {
        ObjectMapper mapper = new ObjectMapper();
        
        // 序列化对象 → JSON 字符串
        User user = new User(1, "Alice");
        String json = mapper.writeValueAsString(user);
        System.out.println("JSON: " + json); // 输出: {"id":1,"name":"Alice"}

        // 反序列化 JSON 字符串 → 对象
        User newUser = mapper.readValue(json, User.class);
        System.out.println("User ID: " + newUser.getId()); // 输出: 1
    }

    // 定义 Java Bean
    static class User {
        private int id;
        private String name;

        // 必须有无参构造函数和 getter/setter
        public User() {}
        public User(int id, String name) { this.id = id; this.name = name; }
        public int getId() { return id; }
        public void setId(int id) { this.id = id; }
        public String getName() { return name; }
        public void setName(String name) { this.name = name; }
    }
}

二、Protocol Buffers（Protobuf）

1. 定义 .proto 文件

// user.proto
syntax = "proto3";
option java_package = "com.example";
option java_outer_classname = "UserProtos";

message User {
  int32 id = 1;
  string name = 2;
}

2. 生成 Java 代码

使用 protoc 编译器生成代码：

protoc --java_out=. user.proto

3. 序列化与反序列化

import com.example.UserProtos.User;

public class ProtobufExample {
    public static void main(String[] args) throws Exception {
        // 序列化对象 → 字节数组
        User user = User.newBuilder().setId(1).setName("Alice").build();
        byte[] data = user.toByteArray();

        // 反序列化字节数组 → 对象
        User newUser = User.parseFrom(data);
        System.out.println("User Name: " + newUser.getName()); // 输出: Alice
    }
}

三、Apache Avro

1. 添加 Maven 依赖

<dependency>
    <groupId>org.apache.avro</groupId>
    <artifactId>avro</artifactId>
    <version>1.11.2</version>
</dependency>

2. 定义 Avro Schema

// src/main/avro/user.avsc
{
  "type": "record",
  "name": "User",
  "fields": [
    {"name": "id", "type": "int"},
    {"name": "name", "type": "string"}
  ]
}

3. 生成 Java 类

使用 Maven 插件生成代码：

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.avro</groupId>
            <artifactId>avro-maven-plugin</artifactId>
            <version>1.11.2</version>
            <executions>
                <execution>
                    <phase>generate-sources</phase>
                    <goals>
                        <goal>schema</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

4. 序列化与反序列化

import org.apache.avro.file.DataFileWriter;
import org.apache.avro.io.DatumWriter;
import org.apache.avro.specific.SpecificDatumWriter;
import java.io.ByteArrayOutputStream;

public class AvroExample {
    public static void main(String[] args) throws Exception {
        // 创建对象
        User user = User.newBuilder().setId(1).setName("Alice").build();

        // 序列化对象 → 字节数组
        ByteArrayOutputStream out = new ByteArrayOutputStream();
        DatumWriter<User> writer = new SpecificDatumWriter<>(User.class);
        DataFileWriter<User> dataFileWriter = new DataFileWriter<>(writer);
        dataFileWriter.create(user.getSchema(), out);
        dataFileWriter.append(user);
        dataFileWriter.close();
        byte[] data = out.toByteArray();

        // 反序列化字节数组 → 对象（需使用 DataFileReader）
        // 此处简化为直接访问对象
        System.out.println("User Name: " + user.getName()); // 输出: Alice
    }
}

四、MessagePack

1. 添加 Maven 依赖

<dependency>
    <groupId>org.msgpack</groupId>
    <artifactId>msgpack-core</artifactId>
    <version>0.9.3</version>
</dependency>

2. 序列化与反序列化

import org.msgpack.core.MessageBufferPacker;
import org.msgpack.core.MessagePack;
import org.msgpack.core.MessageUnpacker;

public class MessagePackExample {
    public static void main(String[] args) throws Exception {
        // 序列化对象 → 字节数组
        MessageBufferPacker packer = MessagePack.newDefaultBufferPacker();
        packer.packInt(1).packString("Alice");
        byte[] data = packer.toByteArray();

        // 反序列化字节数组 → 对象
        MessageUnpacker unpacker = MessagePack.newDefaultUnpacker(data);
        int id = unpacker.unpackInt();
        String name = unpacker.unpackString();
        System.out.println("User ID: " + id); // 输出: 1
    }
}

三、性能对比与选型建议

格式	优点	缺点	适用场景
JSON	可读性强，兼容性广	体积大，序列化速度较慢	REST API、配置存储
Protocol Buffers	高性能，紧凑二进制格式	需预定义 Schema，调试困难	微服务通信、高吞吐场景
Avro	支持动态 Schema，适合大数据	依赖代码生成，生态较弱	Hadoop、Kafka 数据管道
MessagePack	极速序列化，无 Schema 限制	无类型检查，跨语言支持有限	实时通信、内存缓存

最佳实践：

微服务通信：优先选择 Protocol Buffers（性能高）或 JSON（调试方便）。
大数据处理：使用 Avro（支持 Schema 演进）。
实时系统：考虑 MessagePack（速度极快）。

四、优化技巧

预生成代码（Protobuf/Thrift）
- 提前编译 .proto 或 .thrift 文件，减少运行时解析开销。
复用序列化器实例
- 避免重复创建序列化对象（如 Jackson 的 ObjectMapper 应单例使用）。
压缩传输数据
- 结合 GZIP 压缩 JSON/XML 文本数据，减少网络带宽占用。
缓存 Schema（Avro）
- 在 Schema Registry（如 Confluent Schema Registry）中集中管理 Avro Schema，避免重复传输。

总结

消息序列化是分布式系统设计的核心环节，需根据 性能、可读性、跨语言支持、模式演化 需求综合选择：

高性能场景：优先选择二进制格式（Protobuf、Avro）。
调试与兼容性：文本格式（JSON、XML）更优。
实时性要求极高：MessagePack 或自定义二进制协议。

通过合理选型和优化，可显著提升系统吞吐量、降低延迟，并确保数据在不同服务间的可靠传递。

消息过滤与路由详解：原理、策略与实现

消息过滤与路由是消息队列中实现精准消息分发的核心机制，其目标是将消息高效、准确地传递给符合条件的消费者。以下是其基本原理与常见路由策略的深入解析：

一、消息过滤的基本原理

1. 基于内容的路由（Content-Based Routing）

原理：根据消息的 Header 属性 或 正文内容 决定路由路径。
实现方式：
- RabbitMQ：通过 Headers Exchange 匹配消息头的键值对。
- Kafka：消费者自行过滤（如使用 Kafka Streams 处理）。
- RocketMQ：通过 SQL92 表达式过滤消息 Tag。

2. 基于标签的过滤（Tag-Based Filtering）

原理：为消息附加一个或多个标签（Tag），消费者订阅特定标签。
典型应用：
- RocketMQ：消费者订阅时指定 Tag（如 TagA || TagB）。
- Kafka：通过消息 Key 或自定义元数据实现类似功能。

3. 基于 Topic 的通配符匹配

原理：使用通配符（* 匹配一个词，# 匹配多个词）灵活订阅消息。
示例：
- RabbitMQ Topic Exchange：路由键 order.* 匹配 order.create、order.pay。
- MQTT：主题 sensor/+/temperature 匹配所有传感器的温度数据。

二、基于规则的消息路由策略

1. 静态路由策略

固定路由键（Direct Routing）
- 场景：一对一精准匹配（如支付成功通知 → 支付服务）。
- RabbitMQ 实现：
```
// 生产者发送到指定队列
channel.basicPublish("", "payment_queue", null, message.getBytes());
```

广播路由（Fanout）

场景：消息需要广播到多个消费者（如系统配置更新）。

RabbitMQ 实现：

// 声明 Fanout Exchange
channel.exchangeDeclare("config_fanout", "fanout");
// 消费者绑定队列到 Exchange
channel.queueBind("serviceA_queue", "config_fanout", "");

2. 动态路由策略

优先级路由（Priority Queue）

场景：VIP 订单优先处理。

RabbitMQ 实现：

Map<String, Object> args = new HashMap<>();
args.put("x-max-priority", 10); // 队列支持优先级 0-10
channel.queueDeclare("vip_orders", true, false, false, args);

条件路由（Header Exchange）

场景：根据消息头动态路由（如按地区分发订单）。

RabbitMQ 实现：

// 声明 Headers Exchange
channel.exchangeDeclare("orders_header", "headers");
// 绑定队列时指定匹配规则（如 region=us）
Map<String, Object> bindingArgs = new HashMap<>();
bindingArgs.put("x-match", "all"); // 需全部匹配
bindingArgs.put("region", "us");
channel.queueBind("us_orders", "orders_header", "", bindingArgs);

延时路由（Delayed Message）

场景：订单超时自动取消。

RabbitMQ 实现（需安装插件）：

// 发送延时消息（5000ms）
Map<String, Object> headers = new HashMap<>();
headers.put("x-delay", 5000);
AMQP.BasicProperties props = new AMQP.BasicProperties.Builder()
    .headers(headers)
    .build();
channel.basicPublish("delayed_exchange", "order.cancel", props, message.getBytes());

3. 复杂事件路由（CEP）

原理：通过规则引擎（如 Drools、Flink CEP）匹配复合事件。
场景：风控系统中检测连续登录失败。
实现方式：
- Kafka Streams：定义时间窗口内的复杂事件规则。
- RabbitMQ + 外部服务：将消息转发到规则引擎处理。

三、消息队列中的路由实现对比

消息队列	过滤与路由能力	典型应用场景
RabbitMQ	强大的 Exchange 路由模型（Direct/Topic/Headers/Fanout）	企业级系统、复杂路由需求
Kafka	基于分区的简单路由，需消费者自行过滤（如按 Key 哈希）	大数据流水线、日志处理
RocketMQ	SQL 表达式过滤 Tag，支持延时消息和顺序消息	电商交易、金融支付
ActiveMQ	支持 JMS 选择器（Selector）和虚拟 Topic	传统企业应用、JMS 兼容系统

四、性能优化与最佳实践

减少 Broker 负载
- 预处理过滤：在生产者端为消息添加清晰的 Tag 或 Header，避免 Broker 解析消息体。
- 分区设计（Kafka）：按业务键（如用户 ID）分区，保证相同键的消息路由到同一分区。
规则简化
- 避免过度通配符：如 # 在 RabbitMQ 中可能导致性能下降。
- 合并相似路由：将多个条件合并为单个 Tag（如 region=us&type=vip → us_vip）。
监控与告警
- 队列堆积检测：监控未消费消息数量，及时调整路由规则或扩容消费者。
- 规则命中率：分析路由规则的使用情况，淘汰无效规则。

五、典型应用场景

电商订单系统
- 路由策略：
  - order.create → 库存服务扣减库存。
  - order.pay → 支付服务生成交易流水。
  - order.status=timeout → 延时消息触发订单取消。
物联网数据采集
- 过滤规则：传感器数据按类型（温度/湿度）分发到不同处理服务。
- 动态路由：异常数据（如温度 >100℃）触发告警通知。
日志处理系统
- Topic 设计：logs.app.error、logs.app.info。
- 消费者订阅：运维团队订阅 error，分析服务订阅 info。

六、代码示例：RabbitMQ Topic Exchange 路由

// 生产者发送消息到 Topic Exchange
channel.exchangeDeclare("order_events", "topic");
String routingKey = "order.create.us";
channel.basicPublish("order_events", routingKey, null, message.getBytes());

// 消费者1：订阅所有美国订单
channel.queueBind("us_orders", "order_events", "order.*.us");

// 消费者2：订阅所有创建订单事件
channel.queueBind("create_orders", "order_events", "order.create.#");