kafka面试题

1、Kafka 架构

2、Kafka 压力测试
Kafka 官方自带压力测试脚本(kafka-consumer-perf-test.sh、kafka-producer-perf-test.sh)。Kafka 压测时，可以查看到哪个地方出现了瓶颈(CPU，内存，网络 IO)。一般都是网络 IO 达到瓶颈。

3、Kafka 机器数量
Kafka 机器数量 = 2 * (峰值生产速度 * 副本数/100）+ 1

4、 Kafka 日志保存时间
7 天

5、Kafka 的硬盘大小
每天的数据量 * 7 / 70%

6、Kafka 监控
KafkaManager、KafkaMonitor、Kafkaegle

7、Kafka 分区数
分区数并不是越多越好，一般分区数不要超过集群机器数量。分区数越多占用内存越大(ISR 等)，一个节点集中的分区也就越多，当它宕机的时候，对系统的影响也就越大。 分区数一般设置为：3 - 10 个。

8、副本数设定
一般设置为 2 或 3，公司常设置为 2 个。

9、多少个 Topic
通常情况：多少个日志类型就有多少个 Topic。也有对日志类型进行合并的。

10、Kafka 丢不丢数据
Ack = 0，相当于异步发送，消息发送完毕即 offset 增加，继续生产。
Ack = 1，leader 收到 leader replica 对一个消息的接受 ack 才增加 offset，然后继续生产。
Ack = -1，leader 收到所有 replica 对一个消息的接受 ack 才增加 offset，然后继续生产。

11、 Kafka 的 ISR 副本同步队列
ISR(In-Sync Replicas)，副本同步队列。ISR 中包括 Leader 和 Follower。如果 Leader进程挂掉，会在 ISR 队列中选择一个服务作为新的 Leader。有 replica.lag.max.messages（延迟条数）和 replica.lag.time.max.ms（延迟时间）两个参数决定一台服务是否可以加入 ISR 副本队列，在 0.10 版本移除了 replica.lag.max.messages 参数，防止服务频繁的进去队列。 任意一个维度超过阈值都会把 Follower 剔除出 ISR，存入 OSR（Outof-Sync Replicas）列表，新加入的 Follower 也会先存放在 OSR 中。

12、Kafka 分区分配策略
在 Kafka 内部存在两种默认的分区分配策略：Range 和 RoundRobin。

Range 是默认策略。Range 是对每个 Topic 而言的（即一个 Topic 一个 Topic 分），首先对同一个 Topic 里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。然后用 Partitions 分区的个数除以消费者线程的总数来决定每个消费者线程消费几个分区。如果除不尽，那么前面几个消费者线程将会多消费一个分区。

例如：我们有 10 个分区，两个消费者（C1，C2），3 个消费者线程，10 / 3 = 3 而且除不尽。
C1-0 将消费 0, 1, 2, 3 分区
C2-0 将消费 4, 5, 6 分区
C2-1 将消费 7, 8, 9 分区

第一步：将所有主题分区组成 TopicAndPartition 列表，然后对 TopicAndPartition 列表按照 hashCode 进行排序，最后按照轮询的方式发给每一个消费线程。

13、Kafka 中数据量计算
每天总数据量 100 g，每天产生 1 亿条日志，10000 万/24/60/60=1150 条/每秒钟
平均每秒钟：1150 条
低谷每秒钟：50 条
高峰每秒钟：1150 条 *（2-20 倍）=2300 条-23000 条
每条日志大小：0.5k-2k
每秒多少数据量：2.3M-20MB

14、Kafka 挂掉
(1) Flume 记录
(2) 日志有记录
(3) 短期没事

15、Kafka 数据积压，Kafka 消费能力不足怎么处理？
(1) 如果是 Kafka 消费能力不足，则可以考虑增加 Topic 的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。(两者缺一不可)
(2) 如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少(拉取数据/处理时间 < 生产速度)，使处理的数据小于生产的数据，也会造成数据积压。

16、Kafka 幂等性
Producer 的幂等性指的是当发送同一条消息时，数据在 Server 端只会被持久化一次，数据不丟不重，但是这里的幂等性是有条件的：
(1) 只能保证 Producer 在单个会话内不丟不重，如果 Producer 出现意外挂掉再重启是无法保证的(幂等性情况下，是无法获取之前的状态信息，因此是无法做到跨会话级别的不丢不重)。
2）幂等性不能跨多个 Topic-Partition，只能保证单个 Partition 内的幂等性，当涉及多个 Topic-Partition 时，这中间的状态并没有同步。

17、Kafka 事务
Kafka 从 0.11 版本开始引入了事务支持。事务可以保证 Kafka 在 Exactly Once 语义的基础上，生产和消费可以跨分区和会话，要么全部成功，要么全部失败。

(1) Producer 事务
为了实现跨分区跨会话的事务，需要引入一个全局唯一的 Transaction ID，并将 Producer 获得的 PID 和 Transaction ID 绑定。这样当 Producer 重启后就可以通过正在进行的 Transaction ID 获得原来的 PID。
为了管理 Transaction，Kafka 引入了一个新的组件 Transaction Coordinator。Producer 就是通过和 Transaction Coordinator 交互获得 Transaction ID 对应的任务状态。Transaction Coordinator 还负责将事务所有写入 Kafka 的一个内部 Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。

2）Consumer 事务
上述事务机制主要是从 Producer 方面考虑，对于 Consumer 而言，事务的保证就会相对较弱，尤其时无法保证 Commit 的信息被精确消费。这是由于 Consumer 可以通过 offset 访问任意信息，而且不同的 Segment File 生命周期不同，同一事务的消息可能会出现重启后被删除的情况。

18、Kafka 参数调优

19、Kafka 高效读写磁盘