关于kafka

kafka架构

topic partition

kafka为什么很快

消息丢失+消息重复+顺序消费

offset

ISR机制

和其他mq区别

第一个问题：kafka架构

Kafka整体架构详解

一、核心架构组成

Kafka是分布式集群架构，主要由7大核心角色构成：

1. Broker（服务节点） 一台Kafka服务器就是一个Broker。多个Broker组成Kafka集群，集群无中心主节点，所有Broker地位对等，横向扩展简单。单个Broker可承载成千上万个Topic分区。
2. Topic（主题） 消息的分类标识，生产者发消息、消费者收消息都指定Topic。逻辑概念，用来区分不同业务数据（比如订单topic、日志topic）。Topic不存实体数据，数据真正存放在分区。
3. Partition（分区） Topic物理分片。一个Topic拆分成多个Partition分散在不同Broker上。

• 作用：实现水平扩容，让一个Topic的海量数据分散到多台机器；分区可以并行读写，提升吞吐。
• 分区内：消息有序；分区之间全局无序。

1. Replica（副本） 每个Partition有多个副本，分为Leader副本 和Follower副本：

• Leader：所有生产者写入、消费者读取只走Leader。
• Follower：被动同步Leader数据，不处理读写。
• 高可用：Leader宕机，ISR里的Follower自动升级为新Leader，保证数据不丢、服务可用。5Producer（生产者） 消息发送方，业务系统主动往Topic发送消息。生产者自带分区策略，可指定固定分区、轮询分发、按key哈希路由分区。
• 6 Consumer（消费者） 消息消费方，拉取Topic消息做业务处理。
• 7 Consumer Group（消费者组） 一组同名消费者构成消费组。
• 一条消息只会被消费组内一个消费者消费（点对点）；不同消费组互相独立，都能完整消费全量消息（广播效果）。
• 分区分配规则：一个Partition同一时间只能被组内一个消费者消费。消费者数量不能大于分区数，多出来的消费者闲置。

二、配套辅助组件

1. Zookeeper Kafka强依赖ZK，承担：集群Broker注册、Leader分区选举、ISR列表维护、消费者offset存储（新版Kafka可把offset存在Broker）、集群元数据管理。
2. Offset（消息偏移量） 分区内每条消息的唯一顺序编号。

• 生产者：消息写入分区后分配offset。
• 消费者：靠offset标记消费位置，重启后根据offset继续消费，不会从头重刷。

三、整体流转流程

1. 生产者连接ZK获取集群元数据（Topic对应哪些Broker、各分区Leader在哪台机器）。
2. 生产者直连分区Leader Broker发送消息。
3. Leader写入本地磁盘，Follower异步同步数据。
4. 消费者连接ZK查询元数据，直连Leader Broker按offset拉取消息。
5. 消费者处理完消息，提交offset，记录当前消费点位。

四、架构特点总结

1. 分布式分片+多副本，天然支持高可用、水平扩容。
2. 读写全部落在分区Leader，架构简单，吞吐上限高。
3. 消费组+分区绑定，灵活实现点对点/广播两种消费模式。
4. 数据持久化落盘，消息不会消费完立刻删除，支持回溯重消费。

topic partition

Topic & Partition 详细讲解

一、Topic（主题）

1. 定义

Topic是逻辑层面的消息分类 ，用来区分不同业务的消息。 举例：order_topic存订单消息、log_topic存系统日志、pay_topic存支付记录。 生产者发消息、消费者订阅消息，都必须指定Topic。Topic本身不存储真实消息数据，只是逻辑归类。

2. 核心特点

1. 一个集群可以创建成千上万个Topic；
2. Topic可以自定义分区数、副本数；
3. 无全局顺序，Topic只保证业务归类，不保证所有消息有序。

二、Partition（分区）

1. 定义

Partition是Topic的物理分片，是Kafka最小读写单元。创建Topic时会指定分区数量，Topic的数据被拆分分散到各个Partition，分区分布在集群不同Broker机器。

2. 核心规则

1. 分区内有序，分区之间无序 同一个Partition里的消息严格按照写入顺序排列；不同Partition之间消息没有顺序保证。如果业务需要全局有序，只能把Topic设置成1个分区。
2. 横向扩容核心 Topic流量大、数据量大时，增加分区数量，消息分散到更多服务器，读写可以多分区并行，大幅提升整体吞吐量。
3. 分区和副本绑定 每个Partition拥有N个副本（创建Topic指定副本数）：

• Leader副本：负责所有读写请求；
• Follower副本：只同步数据，不处理读写； Leader故障，ISR列表里的Follower竞选新Leader，保障高可用。

三、消息怎么路由到Partition（生产者分区策略）

生产者发送消息时，决定这条消息进入哪个分区，有3种默认策略：

1. 消息指定partition编号：直接发往该分区，优先级最高。
2. 携带key（消息key不为空）：对key做hash取模，固定落到同一个分区。 用处：同一个业务key（比如用户ID、订单号）的消息永远进一个分区，保证该key消息有序。
3. 无key：轮询策略，消息均匀分发到所有可用分区，负载均衡。

四、Partition与消费者组的绑定规则（重点）

1. 同一个消费组中，一个Partition只能被组内一个消费者消费；
2. 消费组消费者数量 ≤ Topic分区数：
   • 消费者数=分区数：一对一，所有消费者都工作，性能最优；
   • 消费者数<分区数：部分消费者消费多个分区；
   • 消费者数>分区数：多余消费者闲置，不会接收消息。
3. 不同消费组互不干扰：所有消费组都能完整消费全部分区数据。

五、Topic和Partition关系总结

1. 一对多：1个Topic = N个Partition；
2. Topic管业务分类，Partition管分布式存储、并发读写、顺序；
3. 分区数是Kafka并发读写的天花板，分区越多理论吞吐越高；
4. 想要部分有序用key哈希分区，想要全局有序只能单分区。

需要我整理极简背诵版，方便面试默写吗？