基础认知
Kafka 是什么？核心定位与核心价值是什么？
Kafka 本质上是一个分布式的消息引擎系统，你可以把它理解成一个巨大的、高性能的管道，专门用来在生产者和消费者之间搬运数据。
它的核心定位就三个字：高吞吐。它不是为了替代 RabbitMQ 那种做业务消息投递的，它的设计目标从一开始就是处理海量数据流，比如日志收集、用户行为埋点、实时计算这些场景。LinkedIn 最早搞 Kafka 就是为了收集自家网站的用户行为日志。
核心价值我总结三点。第一，吞吐量极高，单机就能跑到十几万甚至上百万条消息每秒，其他消息队列跟它不是一个量级。第二，持久化可靠，消息是真正写到磁盘里的，不是放内存里就完事了，而且支持多副本，机器挂了数据也不会丢。第三，横向扩展能力强，加机器就能线性提升吞吐量和容量，集群可以轻松到几百台。
一句话总结：Kafka 就是大数据领域的\”高速公路\”，专门解决海量数据的传输问题。
Kafka 核心架构组成有哪些？各组件（Producer、Consumer、Broker等）核心作用？
Kafka 的架构主要有四大块：Producer、Broker、Consumer、还有 Zookeeper 或者 KRaft。
Producer，就是生产者，负责往 Kafka 里发消息。它会把消息发送到指定的 Topic，而且它很聪明，知道这条消息应该落到哪个分区的哪个 Leader 副本上。
Broker，你可以把它理解成一台台 Kafka 服务器。一个 Kafka 集群由多台 Broker 组成，每台 Broker 上存着一些分区数据，它们互相之间要做数据同步，还要处理生产者和消费者的请求。Broker 本身是无状态的，所有状态信息以前存在 Zookeeper 里，新版存在 KRaft 的元数据日志里。
Consumer，就是消费者，从 Kafka 里拉消息消费。它属于某一个消费者组，组内的各个消费者分摊不同的分区，这样可以并行消费，提升处理速度。消费者自己管理消费到哪了，通过 offset（偏移量）来记录。
还有两个重要的角色要说一下。一个是 Controller，它是 Broker 中的一台，负责管理整个集群的元数据，比如分区 Leader 的选举、Broker 上下线这些事情。另一个是 Coordinator，它分两种，一个是 GroupCoordinator 管消费者组的，负责 rebalance 这些操作；一个是 TransactionCoordinator 管事务的。
Topic、Partition、Replica 三者的核心关系是什么？各自的作用是什么？
这三个概念是层层包含的关系，我打个比方你就好理解了。
Topic 就是一个逻辑上的消息分类，就像你给消息贴了个标签，比如\”订单消息\”、“日志消息”。但这只是一个逻辑概念，数据实际不存 Topic 里。
Partition 是物理上的存储单元，每个 Topic 被分成多个 Partition，数据实际上存在一个个 Partition 里。一个 Partition 就是一个有序的、不可变的消息队列，每条消息在分区内有一个唯一的 offset。分区的作用就是实现并行处理，一个 Topic 的数据分散在多个分区里，你多个消费者就可以同时读不同的分区，吞吐量就上去了。
Replica 是分区的副本，每个分区可以有多个副本，分布在不同的 Broker 上。副本分两种：Leader 和 Follower。Leader 负责处理所有的读写请求，Follower 只干一件事，就是从 Leader 那里同步数据、保持跟 Leader 一致。Follower 存在的唯一意义就是高可用——Leader 所在机器挂了，Follower 里面选一个新的 Leader 顶上。
所以说白了，Topic 是逻辑分类，Partition 是数据分片（做并行），Replica 是数据冗余（做高可用）。
Kafka 为什么吞吐量极高？核心优化机制有哪些？
Kafka 的极高吞吐量是多个设计叠加出来的效果，不是某一点特别牛，是一整套组合拳。
第一个，也是最核心的：顺序读写磁盘。 很多人以为磁盘读写很慢，其实那说的是随机读写。顺序读写磁盘其实非常快，甚至能比随机读写内存还快。Kafka 写消息的时候就是顺序往文件末尾追加，不涉及寻道和旋转延迟，直接利用操作系统的页缓存，速度极快。
第二个，零拷贝技术（Zero Copy）。 传统的数据传输流程是：磁盘 → 内核缓冲区 → 用户空间缓冲区 → 内核 Socket 缓冲区 → 网卡。Kafka 用了 sendfile 系统调用，数据直接从内核缓冲区到网卡，不用经过用户态，省了两次拷贝和两次上下文切换。消费者拉消息的时候基本不耗 CPU。
第三个，批量发送和批量拉取。 Producer 不是来一条消息就发一条，而是攒一批再发，这叫 batch。Consumer 也不是一条一条拉，而是一次拉一批，默认一次拉 500 条。批处理减少了网络往返次数，效率大增。
第四个，消息压缩。 Producer 在发送之前可以对消息进行压缩，比如用 Gzip、Snappy、LZ4 或者 Zstd。压缩之后数据量小了，网络传输和磁盘存储都更省。
第五个，分区并行。 一个 Topic 分成多个分区，分布在不同的 Broker 上，生产和消费都可以并行进行，水平扩展就很简单，加机器就完事了。
第六个，Page Cache（页缓存）。 Kafka 读写数据大量依赖操作系统的页缓存，而不是自己搞一套复杂的缓存机制。写消息的时候写到页缓存就返回了，操作系统自己决定什么时候刷到磁盘。读的时候如果数据还在页缓存里，直接就从内存读，根本不用碰磁盘。
这些加起来，Kafka 的吞吐量就非常恐怖了。
Kafka 适用场景与不适用场景分别是什么？
适用场景主要有这么几个：
第一是日志收集和分析，这是 Kafka 的老本行。各个服务把日志打到 Kafka，下游的 ELK、Splunk 或者自定义分析系统去消费，做一个统一的日志平台。
第二是消息系统，做系统之间的解耦。比如订单系统创建了订单，发一条消息到 Kafka，下游的库存系统、物流系统、通知系统各自去消费，系统之间不直接耦合。
第三是流处理，配合 Flink、Spark Streaming、Kafka Streams 这些框架做实时计算。比如实时统计每五分钟的订单量、实时监控告警。
第四是变更数据捕获（CDC），把数据库的变更（比如 MySQL 的 binlog）捕获出来同步到其他地方，比如做数据同步、缓存刷新。
第五是事件溯源，把每一次状态变更作为事件记录下来，类似一个不可变的账本。
不适用场景也有几个：
第一是延迟要求极低的场景，比如毫秒级的实时调用。Kafka 的设计决定了它的延迟不是最优的，批量和刷盘策略都会增加延迟。这种用 RabbitMQ 更合适。
第二是复杂的路由规则，比如根据消息内容做各种条件匹配分发。Kafka 的路由很简单，就是发到 Topic，Topic 内部
