一、Kafka 是什么

Kafka 不是传统意义上的“消息队列”，它更准确是：

分布式日志系统（Distributed Log System） + 流处理平台

业务场景决定了产品的特点。所以 Kafka 最典型的产品特点有以下几点:

  1. 数据吞吐量很大：需要能够快速收集各个渠道的海量日志
  2. 集群容错性高：允许集群中少量节点崩溃
  3. 功能不需要太复杂：KaKka的设计目标是高吞吐、低延迟和可扩展，主要关注消息传递而不是消息处理。所以，Kaka并没有支持死信队列、顺序消息等高级功能.
  4. 允许少量数据丢失：在海量的应用日志中，少量的日志丢失是不会影响结果的。所以Kaka的设计初衷是允许少量数据丢失的。当然Katka本身也在不断优化数据安全问题

1.1 核心思想

消息不是“消费即删除”（RabbitMQ 思维）而是：消息被持久化存储，消费者自己决定读到哪（offset）

1.2 核心架构

Kafka 的核心组件：

Broker（节点）：Kafka 集群中的一台服务器，负责存储数据 + 提供读写

Topic（主题）：类似 RabbitMQ 的 queue / exchange；逻辑上的分类

示例

user-login-topic
order-topic

Partition（分区）【Kafka 核心】：一个 Topic 会被拆成多个 Partition：

Topic: order-topic

Partition-0  ---> 顺序日志
Partition-1  ---> 顺序日志
Partition-2  ---> 顺序日志

特点

  • 每个 Partition 是有序的
  • Kafka 的“高吞吐”来自：多分区并行读写

Producer（生产者）

负责：发送消息到 Kafka

关键点：可以指定 partition，默认根据 key hash 分区

Consumer（消费者）

负责：从 Kafka 读取消息

重要特点：

  • 主动拉取（pull）
  • 自己维护 offset

Consumer Group（消费组）

Kafka 的消费模型核心：

一个 group 内：
    一个 partition 只能被一个 consumer 消费

效果：

  • 实现负载均衡
  • 实现广播（多个 group）

二，Kafka vs RabbitMQ

维度KafkaRabbitMQ
模型日志流消息队列
消息删除不删除（按时间/大小）消费即删
消费方式pullpush
顺序性partition 内保证queue 保证
吞吐量极高（百万级）较低
使用场景日志、流处理、大数据业务解耦、任务队列

结论：

  • RabbitMQ：业务消息
  • Kafka：数据流/日志流

三，Kafka的集群工作机制

Kafka 集群架构大体如下图：

2953321-20260412222915502-286315687.png

为什么要用集群?

单机服务下，Kafka 已经具备了非常高的性能。TPS 能够达到百万级别。但是，在际工作中使用时，单机搭建的 Kafka 会有很大的局限性。

  • 一方面：消息太多，需要分开保存。Kafka 是面向海量消息设计的，一个 Topic 下的消息会非常多，单机服务很难存得下来。这些消息就需要分成不同的 Partition，分布到多个不同的 Broker 上。这样每个 Broker 就只需要保存一部分数据。这些分区的个数就称为分区数

  • 另一方面：服务不稳定，数据容易丢失。单机服务下，如果服务崩溃，数据就丢失了，为了保证数据安全，就需要给每个 Partation 配置一个或多个备份，保证致据不丢失，Kafka 的集群模式下，每个 Partion 都有一个或多个备份。Kafka 会通过一个统一的 Zookeeper 集群作为选举中心，给每个 Partion 选举出一个主节点 Leader，其他节点就是从节点 Folower。主节点負责响应客户端的具体业务请求，并保存消息。而从节点则负责同步主节点的数据。当主节点发生故障时，Kaftka 会选举出一个从节点成为新的主节点。

  • 最后：Kaka 集群中的这些 Broker 信息，包括 Partition 的选举信息，都会保存在额外部署的 Zookeper 集群当中，这样，kafka 集群就不会因为某一些 Broker 服务崩遗而中断。