前言
Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于年贡献给了Apache基金会并成为顶级开源项目。
关于Kafka的知识总结了个思维导图
kafka面试题
1、如何获取topic主题的列表
2、生产者和消费者的命令行是什么？
3、consumer是推还是拉？
4、讲讲kafka维护消费状态跟踪的方法
5、讲一下主从同步
6、为什么需要消息系统，mysql不能满足需求吗？
7、Zookeeper对于Kafka的作用是什么？
8、数据传输的事务定义有哪三种？
9、Kafka判断一个节点是否还活着有那两个条件？
10、Kafka与传统MQ消息系统之间有三个关键区别
11、讲一讲kafka的ack的三种机制
13、消费者故障，出现活锁问题如何解决？
14、如何控制消费的位置
15、kafka分布式（不是单机）的情况下，如何保证消息的顺序消费?
16、kafka的高可用机制是什么？
17、kafka如何减少数据丢失
18、kafka如何不消费重复数据？比如扣款，我们不能重复的扣。
1、如何获取topic主题的列表
bin/kafka-topics.sh--list--zookeeperlocalhost:
2、生产者和消费者的命令行是什么？
生产者在主题上发布消息：
bin/kafka-console-producer.sh--broker-list..43.49:--topicHello-Kafka
注意这里的IP是server.properties中的listeners的配置。接下来每个新行就是输入一条新消息。
消费者接受消息：
bin/kafka-console-consumer.sh--zookeeperlocalhost:--topicHello-Kafka--from-beginning
3、consumer是推还是拉？
Kafka最初考虑的问题是，customer应该从brokes拉取消息还是brokers将消息推送到consumer，也就是pull还push。在这方面，Kafka遵循了一种大部分消息系统共同的传统的设计：producer将消息推送到broker，consumer从broker拉取消息。
一些消息系统比如Scribe和ApacheFlume采用了push模式，将消息推送到下游的consumer。这样做有好处也有坏处：由broker决定消息推送的速率，对于不同消费速率的consumer就不太好处理了。消息系统都致力于让consumer以最大的速率最快速的消费消息，但不幸的是，push模式下，当broker推送的速率远大于consumer消费的速率时，consumer恐怕就要崩溃了。最终Kafka还是选取了传统的pull模式。
Pull模式的另外一个好处是consumer可以自主决定是否批量的从broker拉取数据。Push模式必须在不知道下游consumer消费能力和消费策略的情况下决定是立即推送每条消息还是缓存之后批量推送。如果为了避免consumer崩溃而采用较低的推送速率，将可能导致一次只推送较少的消息而造成浪费。Pull模式下，consumer就可以根据自己的消费能力去决定这些策略。
Pull有个缺点是，如果broker没有可供消费的消息，将导致consumer不断在循环中轮询，直到新消息到t达。为了避免这点，Kafka有个参数可以让consumer阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特定的量这样就可以批量发送)。
4、讲讲kafka维护消费状态跟踪的方法
大部分消息系统在broker端的维护消息被消费的记录：一个消息被分发到consumer后broker就马上进行标记或者等待customer的通知后进行标记。这样也可以在消息在消费后立马就删除以减少空间占用。
但是这样会不会有什么问题呢？如果一条消息发送出去之后就立即被标记为消费过的，旦consumer处理消息时失败了（比如程序崩溃）消息就丢失了。为了解决这个问题，很多消息系统提供了另外一个个功能：当消息被发送出去之后仅仅被标记为已发送状态，当接到consumer已经消费成功的通知后才标记为已被消费的状态。这虽然解决了消息丢失的问题，但产生了新问题，首先如果consumer处理消息成功了但是向broker发送响应时失败了，这条消息将被消费两次。第二个问题时，broker必须维护每条消息的状态，并且每次都要先锁住消息然后更改状态然后释放锁。这样麻烦又来了，且不说要维护大量的状态数据，比如如果消息发送出去但没有收到消费成功的通知，这条消息将一直处于被锁定的状态，Kafka采用了不同的策略。Topic被分成了若干分区，每个分区在同一时间只被一个consumer消费。这意味着每个分区被消费的消息在日志中的位置仅仅是一个简单的整数：offset。这样就很容易标记每个分区消费状态就很容易了，仅仅需要一个整数而已。这样消费状态的跟踪就很简单了。
这带来了另外一个好处：consumer可以把offset调成一个较老的值，去重新消费老的消息。这对传统的消息系统来说看起来有些不可思议，但确实是非常有用的，谁规定了一条消息只能被消费一次呢？
5、讲一下主从同步
Kafka允许topic的分区拥有若干副本，这个数量是可以配置的，你可以为每个topci配置副本的数量。Kafka会自动在每个个副本上备份数据，所以当一个节点down掉时数据依然是可用的。
Kafka的副本功能不是必须的，你可以配置只有一个副本，这样其实就相当于只有一份数据。
6、为什么需要消息系统，mysql不能满足需求吗？
（1）解耦：
允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
（2）冗余：
消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
（3）扩展性：
因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。
（4）灵活性峰值处理能力：
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
（5）可恢复性：
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
（6）顺序保证：
在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。（Kafka保证一个Partition内的消息的有序性）
（7）缓冲：
有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。
（8）异步通信：
很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
7、Zookeeper对于Kafka的作用是什么？
Zookeeper是一个开放源码的、高性能的协调服务，它用于Kafka的分布式应用。
Zookeeper主要用于在集群中不同节点之间进行通信
在Kafka中，它被用于提交偏移量，因此如果节点在任何情况下都失败了，它都可以从之前提交的偏移量中获取除此之外，它还执行其他活动，如:leader检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等。
8、数据传输的事务定义有哪三种？
和MQTT的事务定义一样都是3种。
（1）最多一次:消息不会被重复发送，最多被传输一次，但也有可能一次不传输
（2）最少一次:消息不会被漏发送，最少被传输一次，但也有可能被重复传输.
（3）精确的一次（Exactlyonce）:不会漏传输也不会重复传输,每个消息都传输被一次而且仅仅被传输一次，这是大家所期望的
9、Kafka判断一个节点是否还活着有那两个条件？
（1）节点必须可以维护和ZooKeeper的连接，Zookeeper通过心跳机制检查每个节点的连接
（2）如果节点是个follower,他必须能及时的同步leader的写操作，延时不能太久
10、Kafka与传统MQ消息系统之间有三个关键区别
(1).Kafka持久化日志，这些日志可以被重复读取和无限期保留
(2).Kafka是一个分布式系统：它以集群的方式运行，可以灵活伸缩，在内部通过复制数据提升容错能力和高可用性
(3).Kafka支持实时的流式处理
11、讲一讲kafka的ack的三种机制
request.required.acks有三个值01-1(all)
0:生产者不会等待broker的ack，这个延迟最低但是存储的保证最弱当server挂掉的时候就会丢数据。
1：服务端会等待ack值leader副本确认接收到消息后发送ack但是如果leader挂掉后他不确保是否复制完成新leader也会导致数据丢失。
-1(all)：服务端会等所有的follower的副本受到数据后才会受到leader发出的ack，这样数据不会丢失
12、消费者如何不自动提交偏移量，由应用提交？
将auto.