📚 课程目录第4章事件通道与中间件

4. 事件通道与中间件：消息队列选型与路由策略

聊到事件治理，绕不开的一个话题就是——消息中间件选型。说白了，事件在系统里怎么跑、跑多快、丢不丢，全看中间件选得对不对。

我见过不少团队，一上来就拍板用 Kafka，理由是“大家都用”。结果业务场景是低频、高可靠的事务消息，Kafka 的 at-least-once 语义和重平衡机制反而成了累赘。反过来，也有人硬拿 RabbitMQ 去扛百万级吞吐的日志流，最后队列堆积到内存爆炸。

所以这一节，咱们把主流的三个选手——Kafka、RabbitMQ、Pulsar——掰开揉碎讲清楚。然后再说事件路由和分区策略，这些才是真正影响业务决策落地的关键。

4.1 三大消息队列的核心差异

先看一张对比表，我习惯用这个表来跟团队做技术选型评审：

维度	Kafka	RabbitMQ	Pulsar
设计哲学	分布式日志流	AMQP 消息代理	云原生消息+流
吞吐量	百万级/秒	万级/秒	百万级/秒
消息模型	Topic + Partition	Exchange + Queue	Topic + Subscription
消息顺序	分区内有序	队列内有序	分区内有序
消息保留	基于时间/大小	消费即删除	分层存储，可回溯
运维复杂度	中高（依赖 ZK）	低	中（无 ZK，但组件多）
典型场景	日志采集、事件流、大数据	任务队列、RPC、事务消息	混合负载、多租户、云原生

我的选型口诀：高吞吐、重回溯选 Kafka；低延迟、强可靠选 RabbitMQ；既要又要还要，上 Pulsar。

4.2 Kafka：日志流的事实标准

Kafka 的核心是“追加日志”。每条消息只追加到 Partition 尾部，消费者自己维护偏移量。这种设计让 Kafka 天生适合高吞吐场景。

我记得有一次帮一家电商公司做订单事件治理。他们每天产生 5 亿条订单状态变更事件，用 RabbitMQ 扛到 3 亿就崩了。换成 Kafka 后，12 个 Broker、48 个分区，轻松跑满。

Kafka 的关键配置：

分区数：建议是 Broker 数的 2~3 倍。太多分区会增加 Leader 选举和文件句柄开销。
副本因子：生产环境至少 2，核心业务建议 3。我踩过副本因子=1 的坑，一台 Broker 宕机直接丢数据。
acks 参数：acks=all 保证最强可靠性，但延迟会高一些。日志类场景用 acks=1 就够了。

# 生产者配置示例
acks=all
retries=3
batch.size=16384
linger.ms=5
compression.type=snappy

我曾经踩过的坑：Kafka 的消费者重平衡（Rebalance）在分区数多、消费者组大的时候，会导致全组停止消费几秒到几十秒。解决方案是使用 Cooperative Sticky Assignor，或者控制单个消费者组的分区数不超过 100。

4.3 RabbitMQ：可靠消息的首选

RabbitMQ 走的是 AMQP 协议，核心是 Exchange 和 Binding。消息先到 Exchange，根据路由键匹配 Binding，再投递到 Queue。

它的优势在于灵活的路由和确认机制。适合那些“每条消息都不能丢”的场景，比如支付回调、订单超时处理。

Exchange 类型对比：

类型	路由逻辑	典型场景
Direct	路由键精确匹配	点对点命令
Topic	路由键通配符匹配	事件分类路由
Fanout	广播给所有绑定队列	全局通知
Headers	根据消息头属性匹配	复杂条件路由

我个人习惯在事件治理中用 Topic Exchange。比如订单事件的路由键设计成 order.created、order.paid、order.shipped，消费者用通配符 order.* 就能订阅所有订单事件。

小技巧：RabbitMQ 的 Publisher Confirm 和 Consumer Ack 一定要同时开启。只开一边，都可能丢消息。我见过只开 Producer Confirm 但 Consumer 自动 Ack 的案例，消费者挂了消息直接丢失。

4.4 Pulsar：云原生时代的搅局者

Pulsar 比较新，但设计理念很超前。它把存储和计算分离了——Broker 只管计算，BookKeeper 管存储。这意味着你可以独立扩缩容 Broker 和存储节点。

Pulsar 还有一个杀手特性：分层存储。消息可以自动从 BookKeeper 卸载到 S3 或 HDFS，保留几个月甚至几年。这在事件溯源和审计场景里非常有用。

Pulsar 的订阅模式：

Exclusive：一个分区只能被一个消费者消费。类似 Kafka 的消费组。
Shared：多个消费者轮流消费消息。适合吞吐量大的场景。
Failover：主消费者挂了，备用的顶上。适合高可用场景。
Key_Shared：相同 Key 的消息路由到同一个消费者。保证有序性。

我最近在帮一个金融客户做实时风控，他们选了 Pulsar。原因很简单：既要高吞吐（每秒 20 万笔交易事件），又要消息回溯（风控规则调整后重新处理过去 7 天的数据）。Kafka 也能做，但 Pulsar 的分层存储让回溯成本低了一个数量级。

4.5 事件路由策略

选好中间件，下一步是设计路由。路由策略决定了事件怎么从生产者到达正确的消费者。

三种常见路由模式：

直接路由：事件直接发送到指定 Topic/Queue。适合点对点通信。
基于内容的路由：根据事件内容（如事件类型、优先级）动态选择目标。RabbitMQ 的 Topic Exchange 就是典型。
基于标签的路由：给事件打标签，消费者订阅感兴趣的标签。Kafka 的 Header 和 Pulsar 的 Key 都支持。

我建议在事件治理中优先用基于内容的路由。为什么呢？因为业务决策往往依赖事件类型和上下文。比如“订单支付成功”事件，既要通知物流系统发货，又要触发积分系统加积分，还要给用户发短信。用内容路由，一个事件可以同时投递到多个目标。

路由设计原则：生产者只负责发布事件，不关心谁消费。路由逻辑由中间件和消费者侧的 Binding/Subscription 决定。这样生产者和消费者完全解耦。

4.6 分区策略：吞吐与有序的博弈

分区策略是 Kafka 和 Pulsar 的核心。它决定了消息怎么分布到不同的分区，直接影响吞吐量和消息顺序。

常见的分区策略：

策略	原理	优点	缺点
轮询	消息轮流发到各分区	负载最均衡	无法保证顺序
Key 哈希	根据 Key 的哈希值选分区	相同 Key 的消息有序	可能数据倾斜
自定义分区器	实现 Partitioner 接口	灵活控制	开发成本高

我遇到过最典型的场景是：订单事件必须按订单 ID 有序。如果同一个订单的“创建”、“支付”、“发货”三个事件被分到不同分区，消费者看到的就是乱序的。

解决方案很简单：用订单 ID 作为 Key，让同一个订单的所有事件进入同一个分区。这样既保证了有序，又实现了负载均衡——不同订单分散到不同分区。

// Kafka 自定义分区器示例
public class OrderKeyPartitioner implements Partitioner {
    @Override
    public int partition(String topic, Object key, byte[] keyBytes,
                         Object value, byte[] valueBytes, Cluster cluster) {
        // 用订单 ID 的哈希值取模
        int partitionCount = cluster.partitionCountForTopic(topic);
        return Math.abs(key.hashCode()) % partitionCount;
    }
}

注意：Key 哈希策略可能导致“热分区”。比如某个爆款商品的订单量是其他商品的 100 倍，那这个 Key 所在的分区就会成为瓶颈。解决办法是给 Key 加盐，或者在业务层面做二次拆分。

4.7 知识体系总览

下面这张图把本章的核心知识点串起来了。你可以把它当作选型和设计的参考地图：

你看，从选型到路由再到分区，每一层都有明确的决策点。选型决定了基础能力，路由决定了事件怎么流动，分区决定了吞吐和有序的平衡。三层叠加，才是完整的事件通道设计。

嗯，这一节的内容就到这里。记住一个原则：没有最好的中间件，只有最适合业务场景的中间件。选型的时候，把吞吐、延迟、可靠性、运维成本四个维度拉出来，跟业务方一起打分，比拍脑袋靠谱得多。