1. Kafka 为什么吞吐量这么高？
Kafka 之所以吞吐量高，主要依赖以下几个设计：
首先，Kafka 采用顺序写磁盘，消息以追加方式写入 Log 文件，避免随机 I/O 带来的性能损耗，使磁盘写入效率非常高。
其次，Kafka 使用零拷贝（Zero Copy）技术，减少数据在用户态和内核态之间的复制，降低 CPU 消耗，提高网络传输效率。
同时，Kafka 支持批量发送和批量消费，将多条消息合并处理，减少网络请求和磁盘 I/O 次数，提高整体吞吐。
另外，Kafka 通过 Partition 分区机制实现水平扩展，不同 Partition 可以并行读写，充分利用多台机器和多核 CPU 的能力。
最后，Kafka 依赖操作系统 Page Cache 缓存热点数据，减少磁盘访问，提高读写性能。
总结来说，Kafka 高吞吐主要依靠：顺序写磁盘 + 零拷贝 + 批量处理 + 分区并行 + Page Cache 优化。这些设计让 Kafka 能够支撑百万级消息吞吐。
2、Kafka 为什么需要 Partition？
首先，Partition 可以实现并行处理。一个 Topic 可以拆分成多个 Partition，不同 Partition 可以分布在不同 Broker 上，由多个 Producer 和 Consumer 并行读写，从而提高系统整体吞吐量。
其次，Partition 提供了水平扩展能力。当数据量增加时，可以通过增加 Partition 数量和 Broker 节点来扩容，而不需要单机承担全部数据压力。
另外，Partition 通过 Offset 保证消息顺序。Kafka 只保证单个 Partition 内的消息有序，不保证多个 Partition 之间的全局顺序，这样可以在性能和顺序之间进行平衡。
3、kafka的ack机制
Kafka 的 ack 机制用于控制 Producer 发送消息后，Broker 需要多少副本确认成功后才认为消息发送成功，主要有三种级别：
-
acks=0
Producer 发送消息后不等待 Broker 响应，直接认为发送成功。性能最高，但可靠性最低，如果消息发送过程中 Broker 宕机，消息可能丢失。
-
acks=1
Producer 发送消息后，只需要 Leader 副本写入成功并返回确认即可。性能和可靠性比较均衡，但如果 Leader 写入成功后还没同步给 Follower 就宕机，可能导致消息丢失。
-
acks=all（或 -1）
Producer 发送消息后，需要 Leader 和所有 ISR（同步副本）都确认写入成功后才返回成功。可靠性最高，可以最大程度避免消息丢失，但吞吐量会有所下降。
4、Kafka 如何保证消息不丢失？
Producer 端通过设置 acks=all，要求所有 ISR（同步副本）都确认消息写入成功后才返回成功，同时可以开启 retries 重试机制，避免网络异常导致消息发送失败。
Broker 端通过 **副本机制（Replication）**保证数据可靠性。每个 Partition 会有多个副本，Leader 负责读写，Follower 负责同步数据。当 Leader 宕机时，可以从 ISR 副本中选举新的 Leader，避免数据丢失。同时可以合理配置 min.insync.replicas，保证至少多个副本同步成功。
Consumer 端通过手动提交 Offset避免消息丢失。消费者处理完消息后再提交 Offset，如果消费过程中失败，Offset 不会提前提交，重新消费时可以继续处理。
5、Kafka 如何保证 Exactly Once
Kafka 保证 Exactly Once（精确一次语义）主要依靠 幂等 Producer + 事务机制 + 消费端 Offset 管理。
首先，Kafka 通过 **幂等 Producer（enable.idempotence=true）**避免消息重复写入。Producer 会为每个消息分配唯一的 Producer ID（PID）和 Sequence Number，Broker 根据这些信息判断重复消息并丢弃，保证单个 Partition 内消息只写入一次。
其次，Kafka 通过 **事务机制（Transaction）**保证多步操作的原子性。例如 Producer 同时向多个 Partition 写消息，或者同时写消息和提交 Offset 时，可以通过事务保证要么全部成功，要么全部失败，避免部分成功导致数据不一致。
另外，在 Consumer 端通常采用 read_committed 模式读取事务消息，只消费已经提交的消息，同时配合 Offset 提交机制，保证消息处理和 Offset 更新的一致性。
例如 Kafka + Flink 场景中，Flink 会开启 Kafka 事务写入，并通过 Checkpoint 保存状态，当任务失败恢复时，可以回滚未提交的数据，从而实现端到端 Exactly Once。
6、Kafka 消息积压如何处理？
Kafka 消息积压定位首先通过 kafka-consumer-groups 查看 Consumer Lag，确认积压的 Topic 和 Partition；然后对比 Producer TPS 和 Consumer TPS，判断是生产过快还是消费能力不足；
如果是消费者处理能力不足，可以增加 Consumer 数量，提高并行度；同时增加 Topic 的 Partition 数量，让更多 Consumer 可以并行消费。另外可以优化消费逻辑，例如批量拉取消息、减少单条消息处理耗时、异步处理耗时任务。
如果是消费端故障或异常导致积压，需要检查消费者日志，解决异常后恢复消费；如果存在消息处理过慢，可以将耗时任务拆分，通过线程池、异步任务等方式提升吞吐。
7、Kafka Rebalance 为什么发生？
Kafka Rebalance 是消费者组重新分配 Partition 的过程，主要发生在 Consumer 加入/退出、心跳超时、消费处理超时、Partition 变化等场景。Rebalance 会导致短暂消费暂停，因此生产环境需要合理设置 session.timeout.ms、heartbeat.interval.ms、max.poll.interval.ms，并减少频繁 Rebalance。
8、Flink 架构是什么？
Flink 架构主要由 Client、Dispatcher、JobManager 和 TaskManager 组成。用户通过client提交任务 → Client 生成 JobGraph → Dispatcher 接收任务 → JobManager 调度任务、分配资源 → TaskManager 启动 Task 执行 → TaskManager 之间进行数据交换 → JobManager 通过 Checkpoint 实现状态管理和故障恢复。
9、Flink 为什么低延迟？
Flink 低延迟主要依靠 真正流式计算、事件驱动模型、Pipeline 执行、内存状态管理以及异步 Checkpoint 机制，避免了批处理等待和频繁磁盘访问，使 Flink 可以实现毫秒级实时计算。
10、Flink Checkpoint是什么？
Flink Checkpoint 是 Flink 的状态一致性快照机制，通过定期保存 Operator 状态和数据源 Offset，在任务失败后进行恢复，同时结合两阶段提交（Two Phase Commit）保证端到端 Exactly Once。例如 Flink 消费 Kafka 数据时，Checkpoint 会保存 Kafka 的 Offset 和算子状态。如果任务失败恢复时，会从 Checkpoint 中的 Offset 继续消费，实现 Exactly Once。
11、Flink 和 Spark Streaming区别？
12、Flink Watermark是什么？
Watermark 是 Flink 用于处理乱序数据的机制，表示某个时间点之前的数据已经基本到齐。当 Watermark 超过窗口结束时间时，Flink 会触发窗口计算。通过设置允许乱序时间，Watermark 可以在保证计算准确性的同时兼顾实时性。
13、Flink Window有哪些？
Flink 常见窗口有四种：滚动窗口（Tumbling）、滑动窗口（Sliding）、会话窗口（Session） 和 全局窗口（Global）。其中滚动窗口无重叠，滑动窗口可重叠，会话窗口根据空闲时间划分，全局窗口需要配合 Trigger 使用；生产环境中最常用的是 Tumbling Window 和 Sliding Window。
14、Flink State有哪些？
Flink State 主要分为 Keyed State 和 Operator State。Keyed State 是按照 Key 隔离的状态，常用于用户级计算，包括 ValueState、ListState、MapState 等；Operator State 是算子级状态，常用于 Source Offset、广播变量等场景。
15、Flink 状态为什么需要 RocksDB？
Flink 使用 RocksDB 主要是因为内存状态无法支撑大规模 State，而 RocksDB 可以利用磁盘扩展状态容量，并支持增量 Checkpoint，提高大状态任务的稳定性。同时 RocksDB 基于 Key-Value 存储，非常适合 Flink Keyed State 的场景。
16、Flink 数据倾斜怎么解决？
Flink 数据倾斜主要是由于热点 Key 导致部分 Task 数据量过大。解决方式包括：对热点 Key 加盐打散、增加并行度、提前预聚合减少 Shuffle、单独处理热点 Key，以及优化 Key 设计。如果是 Join 倾斜，可以使用 Broadcast Join 或调整 Join 策略解决。
17、Flink反压如何产生？
Flink 反压是由于下游算子处理速度低于上游数据产生速度导致的。数据会在网络 Buffer 中堆积，当 Buffer 满后，下游压力会逐渐向上游传播，最终限制 Source 数据读取速度。常见解决方式包括增加并行度、优化算子逻辑、解决数据倾斜、批量写入以及扩容计算资源。