记录消息队列在分布式架构中的核心作用、常见模式与选型思考。

消息队列的核心价值

  1. 异步解耦：上游不需要等待下游处理完成，降低系统耦合度。
  2. 削峰填谷：突发流量写入队列，消费者按自身能力匀速处理。
  3. 最终一致：通过消息重试与死信队列保证数据最终到达。

常见使用模式

点对点（Work Queue）

一个消息只被一个消费者消费，适合任务分发：

Producer → [Queue] → Consumer1
                     Consumer2
                     Consumer3

发布订阅（Pub/Sub）

一个消息被所有订阅者消费，适合事件广播：

Producer → [Topic] → Subscriber1 (邮件服务)
                     Subscriber2 (数据分析)
                     Subscriber3 (审计日志)

主流消息队列对比

维度 Kafka RabbitMQ RocketMQ Pulsar
吞吐量 极高（百万级/s） 中等（万级/s） 高（十万级/s） 高
延迟 毫秒级 微秒级 毫秒级 毫秒级
顺序性 分区内有序 队列内有序 分区内有序 分区内有序
持久化 磁盘日志 可选 磁盘 分离存储
协议 自定义 AMQP 自定义 自定义
适用场景 日志/流处理 业务消息 电商/金融 多租户/流处理

实践中的关键问题

消息可靠性

  • 生产端：开启确认机制（Kafka acks=all，RabbitMQ confirm）。
  • Broker：持久化存储 + 副本机制。
  • 消费端：手动 ack，处理完成后再确认。

消息重复消费

网络抖动可能导致重复投递，消费端必须实现幂等：

1
2
3
4
5
6

# 伪代码：基于唯一 ID 去重
def handle_message(msg):
    if redis.exists(f"processed:{msg.id}"):
        return  # 已处理，跳过
    process(msg)
    redis.setex(f"processed:{msg.id}", 86400, "1")

消息积压

  • 临时扩容消费者实例。
  • 检查消费者是否有慢查询或外部依赖超时。
  • 评估是否需要降级非核心消费逻辑。

消息顺序性

  • 同一业务 key 路由到同一分区/队列。
  • 消费端单线程处理同一分区的消息。
  • 如需全局有序，只能单分区单消费者（牺牲并行度）。

选型建议

  • 日志收集与流处理：Kafka 是事实标准。
  • 业务系统异步通信：RabbitMQ 灵活成熟，协议丰富。
  • 电商交易消息：RocketMQ 事务消息能力强。
  • 多租户 SaaS 平台：Pulsar 存算分离，扩展性好。

小结

消息队列是分布式系统的核心基础设施，选型需综合考虑吞吐、延迟、可靠性和运维成本。后续会记录 Kafka 分区策略与消费者 Rebalance 的实践分析。