1. Kafka入门

各位同学好,我是老张。做了十几年数据管道,跟消息队列打了大半辈子交道。今天咱们开始这门《基于Kafka搭建备份消息管道》的第一章,先把地基打牢。

说实话,我见过太多人一上来就撸代码,结果连Kafka和RabbitMQ的区别都说不清楚。嗯,这样不行。咱们先花点时间,把消息队列是什么、Kafka凭什么这么火、它适合干什么、跟别的MQ比到底好在哪,这几个问题彻底搞明白。

1.1 消息队列是什么?

消息队列,说白了就是一个「中间人」。生产者把消息扔进去,消费者从里面拿。两边不用直接打交道。

举个例子:你点外卖,你(生产者)下单,商家(消费者)接单。如果没有平台做中间人,你得直接打电话给商家,商家忙的时候你还得等。有了平台,你下单就走人,商家有空了再处理。这就是消息队列干的事。

消息队列的核心作用有三个:

  • 解耦——生产者和消费者互不依赖,各自独立演进
  • 削峰填谷——流量高峰时,消息先存起来,下游慢慢消费
  • 异步处理——不需要立即返回结果的操作,扔到队列里后台处理

我个人的理解:消息队列就是系统的「缓冲带」。没有它,上下游直接硬碰硬,一个挂了全挂。有了它,至少能扛住一阵子。

1.2 Kafka核心特性

Kafka最初是LinkedIn开发的,2011年开源。它跟传统消息队列最大的区别在于——它本质上是一个分布式日志系统。

我刚开始接触Kafka时也有点懵:这不就是个消息队列吗?怎么还扯上日志了?后来才明白,Kafka把每条消息都追加到分区日志里,消费者自己维护读取位置。这种设计让它有了几个很硬核的特性:

特性 说明 我的经验
高吞吐 单机每秒百万级消息 我压测过,普通配置的集群扛住几十万TPS很轻松
持久化 消息落盘,可配置保留时间 默认保留7天,我习惯根据业务调整
分区与副本 支持水平扩展,数据冗余 分区数不是越多越好,这个后面会细说
顺序保证 分区内消息有序 跨分区不保证顺序,设计时要注意
消费者组 支持负载均衡和容错 组内消费者数量不要超过分区数

避坑指南:我曾经遇到一个项目,把Kafka当传统队列用,每条消息都等确认才发下一条。结果吞吐量惨不忍睹。记住,Kafka的设计哲学是「批量+顺序」,别跟它对着干。

下面这张图展示了Kafka的核心架构,我画了张SVG帮你理解:

Kafka 核心架构图 生产者 生产者 Kafka Broker 集群 Partition 0 Partition 1 Partition 2 Partition 3 消费者组 Consumer 1 Consumer 2 说明: 生产者将消息发送到Topic的指定分区,Broker负责存储和副本同步。 消费者组内的每个消费者负责消费一个或多个分区,实现并行处理。

1.3 Kafka应用场景

Kafka适合干什么?我总结了几类最常见的场景:

  1. 日志收集——各服务日志统一汇入Kafka,再转存到ES或HDFS。我做过一个项目,每天处理TB级的日志,Kafka扛得稳稳的。
  2. 流式处理——配合Kafka Streams或Flink,做实时计算。比如实时统计、风控检测。
  3. 事件驱动架构——微服务之间通过事件通信,Kafka作为事件总线。
  4. 数据管道——数据库变更捕获(CDC),把MySQL的binlog同步到其他系统。
  5. 消息缓冲——上下游系统处理能力不匹配时,用Kafka做缓冲层。

注意:Kafka不适合做「点对点」的即时消息推送。它的设计目标是高吞吐、持久化,延迟在毫秒级,但不是微秒级。如果你需要实时性极高的消息传递,比如IM聊天,那还是看看别的吧。

1.4 Kafka vs RabbitMQ

这个问题面试经常问,也是很多新手纠结的地方。我直接说结论:没有谁更好,只有谁更合适。

RabbitMQ是传统的消息代理,Kafka是分布式日志系统。两者设计哲学完全不同。下面这张表对比了关键差异:

对比维度 Kafka RabbitMQ
设计理念 分布式日志,消息持久化 消息代理,灵活路由
吞吐量 百万级/秒 万级/秒
消息模型 发布-订阅,消费者拉取 多种模型,支持推拉
消息顺序 分区内严格有序 不保证全局有序
消息确认 偏移量提交 ACK确认机制
路由能力 弱(基于Topic) 强(Exchange+Binding)
运维复杂度 较高(需管理ZooKeeper) 较低
典型场景 大数据管道、日志、流处理 任务队列、RPC、微服务

我个人的选型建议:

  • 如果你需要高吞吐、持久化、顺序保证,选Kafka。比如日志收集、数据同步。
  • 如果你需要灵活路由、复杂消息模式,选RabbitMQ。比如任务分发、延时队列。
  • 如果你两者都需要,那就都用。我在一个项目中同时用了Kafka和RabbitMQ,各司其职。

我的经验:曾经有个团队,用RabbitMQ做日志收集,结果每天几亿条日志把RabbitMQ压垮了。后来换成Kafka,问题迎刃而解。反过来,也有团队用Kafka做任务队列,结果消息路由搞得极其复杂,最后还是换回了RabbitMQ。选对工具,事半功倍。

好了,第一章就到这里。消息队列的概念、Kafka的核心特性、应用场景,以及跟RabbitMQ的对比,咱们都过了一遍。这些是后续所有内容的基础,务必理解透彻。