1. 为什么kafka不支持主从分离？为什么不像redis和mysql可以支持主从分离呢，是因为什么原因要这么设计呢？
      • 对于那种读操作很多而写操作相对不频繁的负载类型而言，采用读写分离是非常不错的方案——我们可以添加很多follower横向扩展，提升读操作性能。反观Kafka，它的主要场景还是在消息引擎而不是以数据存储的方式对外提供读服务，通常涉及频繁地生产消息和消费消息，这不属于典型的读多写少场景，因此读写分离方案在这个场景下并不太适合。
      • Kafka副本机制使用的是异步消息拉取，因此存在leader和follower之间的不一致性。如果要采用读写分离，必然要处理副本lag引入的一致性问题，比如如何实现read-your-writes、如何保证单调读（monotonic reads）以及处理消息因果顺序颠倒的问题。相反地，如果不采用读写分离，所有客户端读写请求都只在Leader上处理也就没有这些问题了——当然最后全局消息顺序颠倒的问题在Kafka中依然存在，常见的解决办法是使用单分区，其他的方案还有version vector，但是目前Kafka没有提供。
    1. 如何清除kafka所有的缓存信息
      1. 关闭集群和ZooKeeper
      2. 删除log.dirs配置的目录下的内容
      3. 删除ZooKeeper路径下的内容
      4. 重启ZooKeeper和集群

    ————————————————— 分割线

    1. Kafka相对传统技术有什么优势?
      • 快速:单一的Kafka代理可以处理成千上万的客户端，每秒处理数兆字节的读写操作。
      • 持久:消息是持久性的，并在集群中进行复制，以防止数据丢失。
      • 设计:它提供了容错保证和持久性
    2. 解释Kafka的Zookeeper是什么?我们可以在没有Zookeeper的情况下使用Kafka吗?
      • Zookeeper是一个开放源码的、高性能的协调服务，它用于Kafka的分布式应用。不，不可能越过Zookeeper，直接联系Kafka broker。一旦Zookeeper停止工作，它就不能服务客户端请求。·Zookeeper主要用于在集群中不同节点之间进行通信
    3. 解释Kafka的用户如何消费信息?
      • 在Kafka中传递消息是通过使用sendfile API完成的。它支持将字节从套接口转移到磁盘，通过内核空间保存副本，并在内核用户之间调用内核。
    4. 简单描述一下Kafka吗？
      • Kafka是一个高吞吐、易扩展的分布式发布-订阅消息系统，它能够将消息持久化到磁盘，用于批量的消费。Kafka中有以下几个概念：
        • Topic：特指Kafka处理的消息源（feeds of messages）的不同分类。
        • Partition：Topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。
        • Broker：Kafa集群中包含一台或多台服务器，这种服务器被称为broker。
        • Producer：生产者，向Kafka的一个topic发布消息。
        • Consumers：消费者，从kafka的某个topic读取消息。
    5. kafka分布式的情况下，如何保证消息的顺序?
      • kafka只能保证partition内是有序的
      • 业务上把需要有序的打到同一个partition，也是一种思路，而且广泛使用。因为大多数情况只需要业务上保证有序就可以，不用全局有序。
    6. kafka特点
      • Kafka具有近乎实时性的消息处理能力，即使面对海量消息也能够高效地存储消息和查询消息。Kafka将消息保存在磁盘中，在其设计理念中并不惧怕磁盘操作，它以顺序读写的方式访问磁盘，从而避免了随机读写磁盘导致的性能瓶颈。
      • Kafka支持批量读写消息，并且会对消息进行批量压缩，这样既提高了网络的利用率，也提高了压缩效率。
      • Kafka支持消息分区，每个分区中的消息保证顺序传输，而分区之间则可以并发操作，这样就提高了Kafka的并发能力。
      • Kafka也支持在线增加分区，支持在线水平扩展。
      • Kafka支持为每个分区创建多个副本，其中只会有一个Leader副本负责读写，其他副本只负责与Leader副本进行同步，这种方式提高了数据的容灾能力。Kafka会将Leader副本均匀地分布在集群中的服务器上，实现性能最大化。
    7. 主题分区的作用？
      • Kafka的每个Topic (主题)都可以分为多个Partition (分区)，每个分区都有多个Replica(副本)，实现消息冗余备份。每个分区中的消息是不同的，这类似于数据库中水平切分的思想，提高了并发读写的能力。
        而同一分区的不同副本中保存的是相同的消息，副本之间是一主多从的关系，其中Leader副本负责处理读写请求，Follower 副本则只与Leader副本进行消息同步，当Leader副本出现故障时，则从Follower 副本中重新选举Leader副本对外提供服务。这样，通过提高分区的数量，就可以实现水平扩展，通过提高副本的数量，就可以提高容灾能力。
    8. Consumer的水平扩展是如何实现的呢？
      • Kafka支持Consumer的水平扩展能力。可以让多个Consumer加入一个Consumer Group(消费组)，在一个Consumer Group中，每个分区只能分配给一个Consumer消费者，当Kafka服务端通过增加分区数量进行水平扩展后，
        可以向Consumer Group中增加新的Consumer来提高整个Consumer Group的消费能力。当Consumer Group中的一个Consumer出现故障下线时，会通过Rebalance操作将下线Consumer，它负责处理的分区将分配给其他Consumer继续处理。当下线Consumer重新上线加人Consumer Group时，会再进行一次Rebalance操作，重新分配分区。
    9. 请简述一下消息的顺序
      • Kafka保证一个Partition内消息的有序性，但是并不保证多个Partition之间的数据有顺序。 每个Topic可以划分成多个分区( 每个Topic都至少有一个分区)，同一Topic下的不同分区包含的消息是不同的。每个消息在被添加到分区时，都会被分配一个offset，它是消息在此分区中的唯一编号，Kafka 通过offset保证消息在分区内的顺序，
        offset 的顺序性不跨分区，即Kafka只保证在同一个分区内的消息是有序的，同一Topic的多个分区内的消息，Kafka并不保证其顺序性
    10. 为了避免磁盘被占满，Katka会周期性地删除陈旧的消息，删除策略是什么呢？
      • Kafka中有两种“保留策略”：一种是根据消息保留的时间，当消息在Kafka中保存的时间超过了指定时间，就可以被删除;
        另一种是根据Topic存储的数据大小，当Topic所占的日志文件大小大于一个阈值，则可以开始删除最旧的消息。Kafka会启动一个后台线程，定期检查是否存在可以删除的消息。“保留策略”的配置是非常灵活的，可以有全局的配置，也可以针对Topic进行配置覆盖全局配置。
    11. 什么是broker？它的作用是什么？
      • 一个单独的Kafka Server就是一个Broker。Broker的主要工作就是接收生产者发过来的消息，分配offset，之后保存到磁盘中。同时，接收消费者、其他Broker的请求，根据请求类型进行相应处理并返回响应。在一般的生产环境中，一个Broker独占一台物理服务器。
    12. 同一分区的多个副本包括的消息是否是一致的？
      • 每个副本中包含的消息是一样的，但是在同一时刻，副本之间其实并不是完全一样的。
    13. Consumer Group中消费者的数量是不是越多越好呢？
      • Consumer Group中消费者的数量并不是越多越好，当其中消费者数量超过分区的数量时，会导致有消费者分配不到分区，从而造成消费者的浪费。
    14. 详述一下消息在kafka中的生命周期？
      • 生产者会根据业务逻辑产生消息，之后根据路由规则将消息发送到指定分区的Leader副本所在的Broker上。在Kafka服务端接收到消息后，会将消息追加到Log中保存，之后Follower副本会与Leader副本进行同步，当ISR集合中所有副本都完成了此消息的同步后，则Leader副本的HW会增加，并向生产者返回响应。
        消费者加人到Consumer Group时，会触发Rebalance操作将分区分配给不同的消费者消费。随后，消费者会恢复其消费位置，并向Kafka服务端发送拉取消息的请求，Leader副本会验证请求的offset以及其他相关信息，最后返回消息。
    15. zookeeper在Kafka中的作用？
      • Kafka使用ZooKeeper集群管理元数据，例如：记录Topic名称、分区以及其副本分配等信息，用户权限控制的相关数据等。Kafka 还会在ZooKeeper的某些上添加相应的监听器，用于监听集群的状态，例如：集群中所有Broker通过ZooKeeper监听Controller Leader的状态。

    有哪些情况下会出现生产消息重复
    一个consumer正在消费一个分区的一条消息，还没有消费完，发生了rebalance(加入了一个consumer)，从而导致这条消息没有消费成功，rebalance后，另一个consumer又把这条消息消费一遍