18道kafka高频面试题（附答案）

题目预览

1、如何获取 topic 主题的列表
2、生产者和消费者的命令行是什么？
3、consumer 是推还是拉？
4、讲讲 kafka 维护消费状态跟踪的方法
5、讲一下主从同步
6、为什么需要消息系统，mysql 不能满足需求吗？
7、Zookeeper 对于 Kafka 的作用是什么？
8、数据传输的事务定义有哪三种？
9、Kafka 判断一个节点是否还活着有那两个条件？
10、Kafka 与传统 MQ 消息系统之间有三个关键区别
11、讲一讲 kafka 的 ack 的三种机制
12、消费者如何不自动提交偏移量，由应用提交？
13、消费者故障，出现活锁问题如何解决？
14、如何控制消费的位置
15、kafka 分布式（不是单机）的情况下，如何保证消息的顺序消费?
16、kafka 的高可用机制是什么？
17、kafka 如何减少数据丢失
18、kafka 如何不消费重复数据？比如扣款，我们不能重复的扣。

题目及答案

1、如何获取 topic 主题的列表
bin/kafka-topics.sh --list --zookeeper localhost:2181

2、生产者和消费者的命令行是什么？
生产者在主题上发布消息：

bin/kafka-console-producer.sh --broker-list 192.168.43.49:9092 --topicHello-Kafka

注意这里的 IP 是 server.properties 中的 listeners 的配置。接下来每个新行就是输入一条新消息。
消费者接受消息：

bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topicHello-Kafka --from-beginning

3、consumer 是推还是拉？
Kafka 最初考虑的问题是，customer 应该从 brokes 拉取消息还是 brokers 将消息推送到 consumer，也就是 pull 还 push。在这方面，Kafka 遵循了一种大部分消息系统共同的传统的设计：producer 将消息推送到 broker，consumer 从broker 拉取消息。
一些消息系统比如 Scribe 和 Apache Flume 采用了 push 模式，将消息推送到下游的 consumer。这样做有好处也有坏处：由 broker 决定消息推送的速率，对于不同消费速率的 consumer 就不太好处理了。消息系统都致力于让 consumer 以最大的速率最快速的消费消息，但不幸的是，push 模式下，当 broker 推送的速率远大于 consumer 消费的速率时，consumer 恐怕就要崩溃了。最终 Kafka 还是选取了传统的 pull 模式。
Pull 模式的另外一个好处是 consumer 可以自主决定是否批量的从 broker 拉取数据 。Push 模式必须在不知道下游 consumer 消费能力和消费策略的情况下决定是立即推送每条消息还是缓存之后批量推送。如果为了避免 consumer 崩溃而采用较低的推送速率，将