一年之计在于春，又是一个跳槽季，大佬已经帮整理了Kafka的进阶面试，真香！先收藏再学习，搞起~~目录 1. kafka的消费者是pull(拉)还是push(推)模式，这种模式有什么优势？ 2. 如何判断Kafka一个节点还活着的有哪两个条件？ 3. 讲一讲 kafka 的 ack 的三种机制(面试题：生产者发送数据的可靠性如何保障的？) 4. kafka 分布式的情况下，如何保证消息的顺序消费? 5. Kafka 消费者端的 Rebalance 操作什么时候发生？ 6. Kafka中的ISR、AR又代表什么？ISR的伸缩又指什么 （面试题： Kafka Replicas是怎么管理的？） 7. 如何确定当前能读到哪一条消息？ 8. 聊一聊你对Kafka的Log Retention（日志留存）的理解 搞起 1. kafka的消费者是pull(拉)还是push(推)模式，这种模式有什么优势？ Kafka 遵循了一种大部分消息系统共同的传统的设计：producer 将消息推送到 broker，consumer 从broker 拉取消息。 优点：pull模式由消费者自主决定是否批量从broker拉取数据，而push模式在无法知道消费者消费能力情况下，不易控制推送速度，太快可能造成消费者奔溃，太慢又可能造成浪费。 缺点：如果 broker 没有可供消费的消息，将导致 consumer 不断在循环中轮询，直到新消息到到达。 为了避免这点，Kafka 有个参数可以让 consumer阻塞直到新消息到达(当然也可以阻塞直到消息的数量达到某个特定的量这样就可以批量发送)。 2. 如何判断Kafka一个节点还活着的有哪两个条件？ （1）节点必须维护和 ZooKeeper 的连接，Zookeeper 通过心跳机制检查每个节点的连接 （2）如果节点是个 follower,他必须能及时的同步 leader 的写操作，延时不能太久 3. 讲一讲 kafka 的 ack 的三种机制(面试题：生产者发送数据的可靠性如何保障的？) request.required.acks 有三个值 0 1 -1(all)，具体如下： 0：生产者不会等待 broker 的 ack，这个延迟最低但是存储的保证最弱当 server 挂掉的时候就会丢数据。 1：服务端会等待 ack 值 leader 副本确认接收到消息后发送 ack 但是如果 leader挂掉后他不确保是否复制完成新 leader 也会导致数据丢失。 -1(all)：服务端会等所有的 follower 的副本受到数据后才会受到 leader 发出的ack，这样数据不会丢失。 4. kafka 分布式的情况下，如何保证消息的顺序消费? Kafka 中发送 1 条消息的时候，可以指定(topic, partition, key) 3 个参数，partiton 和 key 是可选的。 Kafka 分布式的单位是 partition，同一个 partition 用一个 write ahead log 组织，所以可以保证FIFO 的顺序。不同 partition 之间不能保证顺序。因此你可以指定 partition，将相应的消息发往同 1个 partition，并且在消费端，Kafka 保证1 个 partition 只能被1 个 consumer 消费，就可以实现这些消息的顺序消费。 另外，你也可以指定 key（比如 order id），具有同 1 个 key 的所有消息，会发往同 1 个partition，那这样也实现了消息的顺序消息。 5. Kafka 消费者端的 Rebalance 操作什么时候发生？ 同一个 consumer 消费者组 group.id 中，新增了消费者进来，会执行 Rebalance 操作 消费者离开当期所属的 consumer group组。比如宕机分区数量发生变化时(即 topic 的分区数量发生变化时) 消费者主动取消订阅 Rebalance 过程分为两步：Join 和 Sync。 Join,顾名思义就是加入组。这一步中，所有成员都向coordinator发送JoinGroup请求，请求加入消费组。一旦所有成员都发送了JoinGroup请求，coordinator会从中选择一个consumer担任leader的角色，并把组成员信息以及订阅信息发给leader,leader负责消费分配方案的制定。 Sync，这一步leader开始分配消费方案，即哪个consumer负责消费哪些topic的哪些partition。一旦完成分配，leader会将这个方案封装进SyncGroup请求中发给coordinator，非leader也会发SyncGroup请求，只是内容为空。coordinator接收到分配方案之后会把方案塞进SyncGroup的response中发给各个consumer。这样组内的所有成员就都知道自己应该消费哪些分区了。 当 Consumer Group 完成 Rebalance 之后，每个 Consumer 实例都会定期地向 Coordinator 发送心跳请求，表明它还存活着。如果某个 Consumer 实例不能及时地发送这些心跳请求，Coordinator 就会认为该 Consumer 已经 ＂死＂ 了，从而将其从 Group 中移除，然后开启新一轮 Rebalance。 coordinator, Group Coordinator是一个服务，每个Broker在启动的时候都会启动一个该服务。 Group Coordinator的作用是用来存储Group的相关Meta信息，并将对应Partition的Offset信息记录到Kafka内置Topic(__consumer_offsets)中。 第一个加入Consumer Group的Consumer被称为leader。真正的Consumer Rebalance行为是由Consumer Group Leader执行的。 Group Leader首先向Coordinator获取Group中的Consumer成员列表，然后根据Rebalance策略，将partition分配给Consumer Group中的成员，再将分配结果告知Coordinator。 最后，Coordinator将partition分配结果通知给每一个Consumer。在Consumer Rebalance的过程中，所有的Consumer都不允许消费消息。 所以对于Rebalance来说，Coordinator起着至关重要的作用 6. Kafka中的ISR、AR又代表什么？ISR的伸缩又指什么 （面试题： Kafka Replicas是怎么管理的？） ISR:In-Sync Replicas 副本同步队列 AR:Assigned Replicas 所有副本 ISR是由leader维护，follower从leader同步数据有一些延迟，任意一个超过阈值都会把follower剔除出ISR, 存入OSR（Outof-Sync Replicas）列表，新加入的follower也会先存放在OSR中。 AR=ISR+OSR。（包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度） AR kafka分区中，维护了一个AR列表，其中包括了所有的分区的副本编号，AR分为ISR和OSR ISR 同步列表，只有当所有的ISR内的副本都同步了leader中的数据，数据才能被提交，才能被消费者访问 OSR 非同步列表，OSR内的副本是否同步了leader的数据，不影响数据的提交，OSR内的follower只是尽力的去同步leader，数据版本可能落后。 7. 如何确定当前能读到哪一条消息？ 如上图是一个分区日志文件 标识共有7条消息，offset (消息偏移量)分别是0~6 0 代表这个日志文件的开始 HW(High Watermark) 为4，0~3 代表这个日志文件可以消费的区间，消费者只能消费到这四条消息 LEO 代表即将要写入消息的偏移量 offset HW:High Watermark 高水位，取一个partition对应的ISR中最小的LEO作为HW，consumer最多只能消费到HW所在的位置上一条信息。 LEO:LogEndOffset 当前日志文件中下一条待写信息的offset。 HW/LEO这两个都是指最后一条的下一条的位置而不是指最后一条的位置。 LSO:Last Stable Offset 对未完成的事务而言，LSO 的值等于事务中第一条消息的位置(firstUnstableOffset)，对已完成的事务而言，它的值同 HW 相同 LW:Low Watermark 低水位, 代表 AR 集合中最小的 logStartOffset 值 8. 聊一聊你对Kafka的Log Retention（日志留存）的理解 kafka留存策略包括删除和压缩两种 删除: 根据时间和大小两个方式进行删除 大小是整个partition日志文件的大小，超过的会从老到新依次删除 时间指日志文件中的最大时间戳而非文件的最后修改时间。 压缩: 相同key的value只保存一个 压缩过的是clean 未压缩的dirty 压缩之后的偏移量不连续 未压缩时连续。