Kafka 核心知识点灵魂 16 问

        大家好，我是梦想家 Alex，今天为大家带来面试过程中关于 Kafka 核心知识灵魂 16 问 ~ 内容较丰富，建议转发收藏。

1、为什么要使用 Kafka ？

• 缓冲和削峰

        上游数据时有突发流量，下游可能扛不住，或者下游没有足够多的机器来保证冗余，kafka 在中间可以起到一个缓冲的作用，把消息暂存在 kafka 中，下游服务就可以按照自己的节奏进行慢慢处理。

• 解耦和扩展性：

        项目开始的时候，并不能确定具体需求。消息队列可以作为一个接口层，解耦重要的业务流程。只需要遵守约定，针对数据编程即可获取扩展能力。

• 冗余：

        可以采用一对多的方式，一个生产者发布消息，可以被多个订阅 topic 的服务消费到，供多个毫无关联的业务使用。健壮性： 消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进行。

• 异步通信：

        很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们 。

2、Kafka 消费过的消息如何再消费？

        kafka 消费消息的 offset 是定义在 zookeeper 中的， 如果想重复消费 kafka 的消息， 可以在 redis 中自己记录 offset 的 checkpoint 点（n 个），当想重复消费消息时，通过读取 redis 中的 checkpoint 点进行 zookeeper 的 offset 重设，这样就可以达到重复消费消息的目的了 。

3、kafka 的数据是放在磁盘上还是内存上，为什么速度会快？

        kafka 使用的是磁盘存储。

        速度快是因为：

• 顺序写入：

        因为硬盘是机械结构，每次读写都会寻址->写入，其中寻址是一个“机械动作”，它是耗时的。所以硬盘 “讨厌”随机 I/O， 喜欢顺序 I/O。为了提高读写硬盘的速度，Kafka 就是使用顺序 I/O。

• Memory Mapped Files（内存映射文件）：

        64 位操作系统中一般可以表示 20G 的数据文件，它的工作原理是直接利用操作系统的 Page 来实现文件到物理内存的直接映射。完成映射之后你对物理内存的操作会被同步到硬盘上。

• Kafka 高效文件存储设计：

         Kafka 把 topic 中一个 parition 大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。通过索引信息可以快速定位 message 和确定 response 的 大 小。通过 index 元数据全部映射到 memory（内存映射文件），可以避免 segment file 的 IO 磁盘操作。通过索引文件稀疏存储，可以大幅降低 index 文件元数据占用空间大小。

4、Kafka 数据怎么保障不丢失

        这里需要分成三个点说，一个是生产者端，一个消费者端，一个 broker 端 。

• 生产者数据不丢失

        kafka 的 ack 机制：在 kafka 发送数据的时候，每次发送消息都会有一个确认反馈机制，确保消息正常的能够被收到，其中状态有 0，1，-1。

如果是同步模式：

        ack 设置为 0，风险很大，一般不建议设置为 0。即使设置为 1，也会随着 leader 宕机丢失数据。所以如果要严格保证生产端数据不丢失，可设置为-1 。

如果是异步模式：

        也会考虑 ack 的状态，除此之外，异步模式下的有个 buffer，通过 buffer 来进行控制数据的发送，有两个值来进行控制，时间阈值与消息的数量阈值，如果 buffer 满了数据还没有发送出去，有个选项是配置是否立即清空 buffer。可以设置为-1，永久阻塞， 也就数据不再生产。异步模式下，即使设置为-1。也可能因为程序员的不科学操作，操作数据丢失，比如 kill -9，但这是特别的例外情况。

注：ack=0：producer 不等待 broker 同步完成的确认，继续发送下一条(批)信息。ack=1（默认）：producer 要等待 leader 成功收到数据并得到确认，才发送下一条 message。ack=-1：producer 得到 follwer 确认，才发送下一条数据。

• 消费者数据不丢失        通过 offset commit 来保证数据的不丢失，kafka 自己记录了每次消费的 offset 数值， 下次继续消费的时候，会接着上次的 offset 进行消费。

        而 offset 的信息在 kafka0.8 版本之前保存在 zookeeper 中，在 0.8 版本之后保存到 topic 中，即使消费者在运行过程中挂掉了，再次启动的时候会找到 offset 的值，找到之前消费消息的位置，接着消费，由于 offset 的信息写入的时候并不是每条消息消费完成后都写入的，所以这种情况有可能会造成重复消费，但是不会丢失消息 。

        唯一例外的情况是，我们在程序中给原本做不同功能的两个 consumer 组设置 。

KafkaSpoutConfig.bulider.setGroupid 的时候设置成了一样的 groupid，这种情况会导致这两个组共享同一份数据，就会产生组 A 消费 partition1，partition2 中的消息，组 B 消费 partition3 的消息，这样每个组消费的消息都会丢失，都是不完整的。为了保证每个组都独享一份消息数据，groupid 一定不要重复才行。

• kafka 集群中的 broker 的数据不丢失

        每个 broker 中的 partition 我们一般都会设置有 replication（副本）的个数，生产者写入的时候首先根据分发策略（有 partition 按 partition，有 key 按 key，都没有轮询）写入到 leader 中，follower（副本）再跟 leader 同步数据，这样有了备份，也可以保证消息数据的不丢失 。

5、kafka 数据分区和消费者的关系？

        每个分区只能由同一个消费组内的一个消费者(consumer)来消费，可以由不同的消费组的消费者来消费，同组的消费者则起到并发的效果 。

6、采集数据为什么选择 kafka？

        在采集层，主要可以使用 Flume, Kafka 等技术 。

        Flume：Flume 是管道流方式，提供了很多的默认实现，让用户通过参数部署，及扩展 API 。

        Kafka：Kafka 是一个可持久化的分布式的消息队列。 Kafka 是一个非常通用的系统。你可以有许多生产者和很多的消费者共享多个主题 Topics 。

        相比之下,Flume 是一个专用工具被设计为旨在往 HDFS，HBase 发送数据。它对 HDFS 有特殊的优化，并且集成了 Hadoop 的安全特性。

        所以，Cloudera 建议如果数据被多个系统消费的话，使用 kafka；如果数据被设计给 Hadoop 使用，使用 Flume。

7、kafka 的数据 offset 读取流程

        连接 ZK 集群，从 ZK 中拿到对应 topic 的 partition 信息和 partition 的 Leader 的相关信息连接到对应 Leader 对应的 brokerconsumer 将自己保存的 offset 发送给 LeaderLeader 根据 offset 等信息定位到 segment（索引文件和日志文件）根据索引文件中的内容，定位到日志文件中该偏移量对应的开始位置读取相应长度的数据并返回给 consumer 。

8、kafka 重启是否会导致数据丢失？

        kafka 是将数据写到磁盘的，一般数据不会丢失。但是在重启 kafka 过程中，如果有消费者消费消息，那么 kafka 如果来不及提交 offset，可能会造成数据的不准确（丢失或者重复消费）。

9、kafka 宕机了如何解决？

• 先考虑业务是否受到影响：

        kafka 宕机了，首先我们考虑的问题应该是所提供的服务是否因为宕机的机器而受到影响，如果服务提供没问题，如果实现做好了集群的容灾机制，那么这块就不用担心了。

• 节点排错与恢复

        想要恢复集群的节点，主要的步骤就是通过日志分析来查看节点宕机的原因，从而解决，重新恢复节点 。

10、为什么 Kafka 不支持读写分离？

        在 Kafka 中，生产者写入消息、消费者读取消息的操作都是与 leader 副本进行交互的，从 而实现的是一种主写主读的生产消费模型。

        Kafka 并不支持主写从读，因为主写从读有 2 个很明显的缺点 :

1. 数据一致性问题：

        数据从主节点转到从节点必然会有一个延时的时间窗口，这个时间窗口会导致主从节点之间的数据不一致。某一时刻，在主节点和从节点中 A 数据的值都为 X， 之后将主节点中 A 的值修改为 Y，那么在这个变更通知到从节点之前，应用读取从节点中的 A 数据的值并不为最新的 Y，由此便产生了数据不一致的问题 。

1. 延时问题：

        类似 Redis 这种组件，数据从写入主节点到同步至从节点中的过程需要经历 网络→主节点内存→网络→从节点内存 这几个阶段，整个过程会耗费一定的时间。而在 Kafka 中，主从同步会比 Redis 更加耗时，它需要经历 网络→主节点内存→主节点磁盘→网络→从节点内存→从节点磁盘 这几个阶段 。对延时敏感的应用而言，主写从读的功能并不太适用 。

        而 kafka 的主写主读的优点就很多了：

        可以简化代码的实现逻辑，减少出错的可能; 将负载粒度细化均摊，与主写从读相比， 不仅负载效能更好，而且对用户可控 ; 没有延时的影响 ; 在副本稳定的情况下，不会出现数据不一致的情况 。

11、Kafka 消息数据积压，Kafka 消费能力不足怎么处理？

        如果是 Kafka 消费能力不足，则可以考虑增加 Topic 的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。（两者缺一不可）

        如果是下游的数据处理不及时： 提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压 。

12、Kafka 单条日志传输大小

        kafka 对于消息体的大小默认为单条最大值是 1M 但是在我们应用场景中, 常常会出现一条消息大于 1M，如果不对 kafka 进行配置。则会出现生产者无法将消息推送到 kafka 或消费者无法去消费 kafka 里面的数据, 这时我们就要对 kafka 进行以下配置：

server.properties

1replica.fetch.max.bytes: 1048576 broker 可复制的消息的最大字节数, 默认为 1M 2message.max.bytes: 1000012 kafka 会接收单个消息 size 的最大限制， 默认为1M 左右

复制代码

注意：message.max.bytes 必须小于等于 replica.fetch.max.bytes，否则就会导致 replica 之间数据同步失败

13、kafka 内部如何保证顺序，结合外部组件如何保证消费者的顺序？

        kafka 只能保证 partition 内是有序的，但是 partition 间的有序是没办法的。我们常用的做法，是从业务上把需要有序的打到同一个 partition 。