1. kafka是什么，应用场景有哪些
1.1 Kafka是一个分布式流式处理平台。
流平台具有三个关键功能：
- 消息队列：发布和订阅消息流，这个功能类似于消息队列，这也是 Kafka 也被归类为消息
队列的原因。 - 容错的持久方式存储记录消息流： Kafka 会把消息持久化到磁盘，有效避免了消息丢失的
风险。 - 流式处理平台： 在消息发布的时候进行处理，Kafka 提供了一个完整的流式处理类库。
1.2 Kafka主要有两大应用场景：
- 消息队列 ：建立实时流数据管道，以可靠地在系统或应用程序之间获取数据。
- 数据处理： 构建实时的流数据处理程序来转换或处理数据流。
2. 和其他消息队列相比,Kafka 的优势在哪里？
- 极致的性能：基于 Scala 和 Java 语言开发，设计中大量使用了批量处理和异步的思想，最高可以每秒处理千万级别的消息。
- 生态系统兼容性无可匹敌：Kafka 与周边生态系统的兼容性是最好的没有之一，尤其在大数据和流计算领域。
3. 什么是 Producer、Consumer、Broker、Topic、Partition？
3.1 几个概念：
- Producer（生产者）: 产生消息的一方。
- Consumer（消费者）: 消费消息的一方。
- Broker（代理）: 可以看作是一个独立的 Kafka 实例。多个 Kafka Broker 组成一个Kafka Cluster。
- Topic（主题）: Producer 将消息发送到特定的主题，Consumer 通过订阅特定的Topic(主题) 来消费消息。
- Partition（分区） : Partition 属于 Topic 的一部分。一个 Topic 可以有多个Partition ，并且同一 Topic 下的 Partition 可以分布在不同的 Broker 上，这也就表明一
个 Topic 可以横跨多个Broker 。这正如我上面所画的图一样。
3.2 大概流程：
- Kafka 将生产者发布的消息发送到Topic（主题）中，需要这些消息的消费者可以订阅这些Topic（主题）;
- 每个Topic被切分成若干个part放入不同的分区中，比如Topic A分成A1、A2、A3分成三部分，分别放入放入P1、P2、P3中;
- 不同的分区可以存放在不同的Broker中，也可以存放在相同的Broker中，比如{“B1”:”P1”, “B2”:”P2,P3”}、{“B1”:”P1,P2”, “B2”:”P3”}等；
- 同一个分区有多个副本（Replica），这些副本都是相同的，每个Broker中存放一个分区的副本；
- 同一个分区的副本可以分为两种：leader副本、follower副本（又可以分为ISR副本和普通副本），我们发送的消息会被发送到
leader副本，然后follower副本才能从leader副本中拉取消息进行保存，ISR是同步保存leader副本，普通副本是异步保存leader副本。
4. Kafka 的多副本机制
Kafka 为分区（Partition）引入了多副本（Replica）机制。
分区（Partition）中的多个副本之间一个叫做 leader，其他副本称为follower。
我们发送的消息会被发送到leader 副本，然后follower副本才能从 leader 副本中拉取消息进行保存同步。
生产者和消费者只与leader副本交互。其他副本只是 leader 副本的拷贝，它们的存在只是为了保证消息存储的安全性。
当leader副本发生故障时会从follower中选举出一个leader，优先从ISR中选举一个follower为leader。
5. Kafka 的多分区（Partition）以及多副本（Replica）机制有什么好处呢？
- Kafka通过给特定Topic指定多个Partition, 而各个Partition可以分布在不同的Broker上, 这样便能提供比较好的并发能力（负载均衡）。
- Partition可以指定对应的Replica数量, 这也极大地提高了消息存储的安全性, 提高了容灾能力，不过也相应的增加了所需要的存储空间。
6. Kafka 如何保证消息的消费顺序？
这个问题可以从两个方面来回答：kafka 为什么会存在无序消费、kafka 如何保证有序消费。
首先，在 kafka 的架构里面，用到了 Partition 分区机制来实现消息的物理存储，
在同一个 topic 下面，可以维护多个 partition 来实现消息的分片。
生产者在发送消息的时候，会根据消息的 key 进行取模，来决定把当前消息存储到哪个 partition 里面，
并且消息是按照先后顺序有序存储到 partition 里面的。
在这种情况下，假设有一个 topic 存在三个 partition，消息的消费顺序不是按照发送顺序来实现的，从而导致乱序的问题。
第一种保证消息消费顺序的方法：1 个Topic只对应一个Partition。
第二种保证消息消费顺序的方法：Kafka 中发送 1 条消息的时候，可以指定 topic, partition, key, data（数据） 4 个参数。
如果你发送消息的时候指定了 Partition 的话，所有消息都会被发送到指定的 Partition。
总结一下，对于如何保证 Kafka 中消息消费的顺序，有了下面两种方法：
- 1 个 Topic 只对应一个 Partition。
- 发送消息的时候指定 key/Partition。
7. kafka 如何保证消息不丢失？
- kafka 是一个用来实现异步消息通信的中间件，它的整个架构由Producer、Consumer、Broker 组成。所以，对于 kafka 如何保证消息不丢失这个问题，可以从三个方面来考虑和实现。
- 首先是 Producer 端，需要确保消息能够到达 Broker 并实现消息存储，在这个层面，有可能出现网络问题，导致消息发送失败，所以，针对 Producer 端，可以通过2种方式来避免消息丢失
- Producer 默认是异步发送消息，这种情况下要确保消息发送成功，有两个方法
- 把异步发送改成同步发送，这样 producer 就能实时知道消息发送的结果。
- 添加异步回调函数来监听消息发送的结果，如果发送失败，可以在回调中重试。
- Producer 本身提供了一个重试参数 retries，如果因为网络问题或者Broker 故障导致发送失败，Producer 会自动重试。
- Producer 默认是异步发送消息，这种情况下要确保消息发送成功，有两个方法
- 然后是 Broker 端，Broker 需要确保 Producer 发送过来的消息不会丢失，也就是只需要把消息持久化到磁盘就可以了。
- 最后是 Consumer 端，消息在被追加到 Partition(分区)的时候都会分配一个特定的偏移量（offset）。
偏移量（offset)表示 Consumer 当前消费到的 Partition(分区)的所在的位置。
Kafka 通过偏移量（offset）可以保证消息在分区内的顺序性。
当消费者拉取到了分区的某个消息之后，消费者会自动提交了 offset。自动提交的话会有
一个问题，当消费者刚拿到这个消息准备进行真正消费的时候，突然挂掉了，消息
实际上并没有被消费，但是 offset 却被自动提交了。
解决办法是，我们手动关闭自动提交 offset，每次在真正消费完消息之后再自己
手动提交 offset。 但是，这样会带来消息被重新消费的问题。比如
消费者刚刚消费完消息之后，还没提交 offset，结果自己挂掉了，那么这个消息理论上就会被消费
两次。
8. Kafka 中一个 Topic 有三个Partition，同一个消费组中两个消费者如何消费的？
这个问题涉及到Kafka里面的Consumer Group Coordinator ，也就是消费组协调器。
它会根据消费者订阅的 Topic 中的 partition 数量、和消费组中的消费者实例数量来决定每个消费者消费哪些 Partition。
这个算法会在消费组中选择一个消费者实例作为 Leader，Leader 负责分配 Partition 给消费者实例，
并协调消费者实例之间的Partition分配和reblance。
当一个消费者实例加入或离开消费组的时候，协调器会触发 Partition 的重新分配，
确保所有 Partition 都能被消费者实例均匀地消费。
