大数据面试之kafka重点（一）

大数据面试之kafka重点（一）
Kafka面试题
介绍下Kafka，Kafka的作用？Kafka的组件？适用场景？
可回答：1）Kafka基本原理；2）下Kafka你知道的东西；3）为什么用Kafka
问过的一些公司：阿里x4，字节x2，字节(2021.07)，快手x3，头条，腾讯x2，小米x3，蘑菇街x3，猿辅 导，网易，京东x2，京东(2021.07)，小鹏汽车，祖龙娱乐，跟谁学，星环科技，大华(2021.07)，58同城(2021.08)，海康(2021.08)
参考答案：
Kafka是一种分布式、高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动 作流数据，主要应用于大数据实时处理领域。简单地说，Kafka就相比是一个邮箱，生产者是发送邮件 的人，消费者是接收邮件的人，Kafka就是用来存东西的，只不过它提供了一些处理邮件的机制。
1、作用

1. 发布和订阅消息流
2. 以容错的方式记录消息流，kafka以文件的方式来存储消息流
3. 可以在消息发布的时候进行处理
   2、优势
   高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒； 可扩展性：kafka集群支持热扩展；
   持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失；
   容错性：允许集群中节点故障（若副本数量为n,则允许n-1个节点故障）；
   高并发：支持数千个客户端同时读写。
   3、组件
   
   ：可以理解为一个队列，生产者和消费者面向的都是一个 topic；
   ：消息生产者，就是向 kafka broker 发消息的客户端；
   Topic
   Producer
   Consumer ：消息消费者，向 kafka broker 取消息的客户端；
   ：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker可以容纳多个
   Broker
   topic。
   4、使用场景
4. 在系统或应用程序之间构建可靠的用于传输实时数据的管道，消息队列功能
5. 构建实时的流数据处理程序来变换或处理数据流，数据处理功能通俗一点来说
   日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种
   consumer；
   消息系统：解耦生产者和消费者、缓存消息等；
   用户活动跟踪：kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活 动，这些活动信息被各个服务器发布到kafka的topic中，然后消费者通过订阅这些topic来做实时的监控 分析，亦可保存到数据库；
   运营指标：kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集 中反馈，比如报警和报告；
   流式处理：比如Spark streaming和Flink。

Kafka作为消息队列，它可解决什么样的问题？
问过的一些公司：Shopee(2021.07) 参考答案：
kafka是消息中间件的一种，它可以让合适的数据以合适的形式出现在合适的地方。Kafka的做法是提供 消息队列，让生产者单往队列的末尾添加数据，让多个消费者从队列里面依次读取数据然后自行处理。
Kafka主要用途是数据集成，或者说是流数据集成，以Pub/Sub形式的消息总线形式提供。但是，Kafka
不仅仅是一套传统的消息总线，本质上Kafka是分布式的流数据平台，因为以下特性而著名：
提供Pub/Sub方式的海量消息处理。以高容错的方式存储海量数据流。保证数据流的顺序。
缓冲和削峰：上游数据时有突发流量，下游可能扛不住，或者下游没有足够多的机器来保证冗余， kafka在中间可以起到一个缓冲的作用，把消息暂存在kafka中，下游服务就可以按照自己的节奏进行慢 慢处理。
解耦和扩展性：项目开始的时候，并不能确定具体需求。消息队列可以作为一个接口层，解耦重要的业 务流程。只需要遵守约定，针对数据编程即可获取扩展能力。
冗余：可以采用一对多的方式，一个生产者发布消息，可以被多个订阅topic的服务消费到，供多个毫无 关联的业务使用。
健壮性：消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进行。
异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一 个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理 它们。

说下Kafka架构
可回答：1）Kafka中producer，broker，cousumer的关系；2）Kafka中topic和partition和broker的关系；

1. Kafka的相关结构；4）说一下Kafka的topic，partition，和副本
   问过的一些公司：字节x2，阿里，网易x2，转转，昆仑万维，触宝(2021.07)，soul(20210.09)，京东
   (20210.09)
   参考答案：
   Kafka基础架构

为方便扩展，并提高吞吐量，一个topic分为多个partition
配合分区的设计，提出消费者组的概念，组内每个消费者并行消费为提高可用性，为每个partition增加若干副本，类似NameNode HA

1）Producer：消息生产者，就是向kafka broker发消息的客户端； 2）Consumer：消息消费者，向kafka broker取消息的客户端；

1. Consumer Group（CG）：消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者 组，即消费者组是逻辑上的一个订阅者。
2. Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个
   topic。
3. Topic ：可以理解为一个队列，生产者和消费者面向的都是一个topic；
4. Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可 以分为多个partition，每个partition是一个有序的队列；
5. Replica：副本，为保证集群中的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍 然能够继续工作，kafka提供了副本机制，一个topic的每个分区都有若干个副本，一个leader和若干个follower。
6. leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是leader。
7. follower：每个分区多个副本中的“从”，实时从leader中同步数据，保持和leader数据的同步。leader
   发生故障时，某个follower会成为新的leader。

说下Kafka的特点，优缺点
问过的一些公司：字节x2，快手，猿辅导，深信服参考答案：
特点
高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒；
可扩展性：kafka集群支持热扩展；

持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失； 容错性：允许集群中节点故障（若副本数量为n,则允许n-1个节点故障）；
高并发：支持数千个客户端同时读写。
优点
支持多个生产者和消费者支持broker的横向拓展
副本集机制，实现数据冗余，保证数据不丢失通过topic将数据进行分类
通过分批发送压缩数据的方式，减少数据传输开销，提高吞高量
支持多种模式的消息
基于磁盘实现数据的持久化
高性能的处理}信息，在大数据的情况下，可以保证亚秒级的消息延迟一个消费者可以支持多种topic的消息
对CPU和内存的消耗比较小
对网络开销也比较小
支持跨数据中心的数据复制支持镜像集群
缺点
由于是批量发送，所以数据达不到真正的实时对于mqtt协议不支持
不支持物联网传感数据直接接入
只能支持统一分区内消息有序，无法实现全局消息有序监控不完善，需要安装插件
需要配合zookeeper进行元数据管理
会丢失数据，并且不支持事务
可能会重复消费数据，消息会乱序，可用保证一个固定的partition内部的消息是有序的，但是一个topic有多个partition的话，就不能保证有序了，需要zookeeper的支持，topic一般需要人工创建， 部署和维护一般都比mq高
四大主流MQ（kafka、ActiveMQ、RabbitMQ、RocketMQ）各自的优缺点

Kafka相比于其它消息组件有什么好处？
可回答：Kafka跟其它的消息队列的对比情况
问过的一些公司：阿里，蘑菇街，美团，虎牙(2021.09) 参考答案：
分布式可扩展。Kafka集群可以透明的扩展，增加新的服务器进集群。
高性能。Kafka 的性能大大超过传统的ActiveMQ、RabbitMQ等MQ实现，尤其是Kafka还支持batch操作。
容错。Kafka每个Partition的数据都会复制到几台服务器上。当某个Broker故障失效时，ZooKeeper服务 将通知生产者和消费者，生产者和消费者转而使用其它Broker。

Kafka生产者与消费者
问过的一些公司：大华(2021.07)，荣耀(2021.09) 参考答案：

生产者：Producer
即消息的发布者，生产者将数据发布到他们选择的主题。
生产者负责选择将哪个记录分配给主题中的哪个分区。即：生产者生产的一条消息，会被写入到某一个
Partition。
消费者：Consumer
可以从Broker中读取消息。
Kafka的消费者，一个消费者可以消费多个Topic的消息；一个消费者可以消费同一个Topic中的多个Partition中的消息；一个Partiton允许多个Consumer同时消费。

Kafka分区容错性
问过的一些公司：大华(2021.08) 参考答案：
Kafka集群中，单个节点或多个节点出问题（主要是网络问题）后，正常服务的服务器依然能正常提供 服务，并且满足设计好的一致性和可用性。
重点在于：部分节点因网络问题，业务依然能够继续运行。如果是整个网络都出现故障，那就没辙了。

Kafka的消费端的数据一致性
问过的一些公司：京东(2021.09) 参考答案：
这里介绍的数据一致性主要是说不论是老的Leader还是新选举的Leader，Consumer都能读到一样的数 据。那么Kafka是如何实现的呢？

假设分区的副本为3，其中副本0是 Leader，副本1和副本2是 follower，并且在 ISR 列表里面。虽然副本0 已经写入了 Message3，但是 Consumer 只能读取到 Message1。因为所有的 ISR 都同步了 Message1，只有 High Water Mark 以上的消息才支持 Consumer 读取，而 High Water Mark 取决于 ISR 列表里面偏移量最小的分区，对应于上图的副本2，这个很类似于木桶原理。

这样做的原因是还没有被足够多副本复制的消息被认为是“不安全”的，如果 Leader 发生崩溃，另一个副本成为新 Leader，那么这些消息很可能丢失了。如果我们允许消费者读取这些消息，可能就会破坏一致性。试想，一个消费者从当前 Leader（副本0） 读取并处理了 Message4，这个时候 Leader 挂掉了，选举了副本1为新的 Leader，这时候另一个消费者再去从新的 Leader 读取消息，发现这个消息其实并不存在，这就导致了数据不一致性问题。
当然，引入了 High Water Mark 机制，会导致 Broker 间的消息复制因为某些原因变慢，那么消息到达消费者的时间也会随之变长（因为我们会先等待消息复制完毕）。延迟时间可以通过参数
参数配置，它指定了副本在复制消息时可被允许的最大延迟时间。
replica.lag.time.max.ms

Kafka的leader挂掉之后处理方法
问过的一些公司：京东(2021.09) 参考答案：
当leader挂掉之后，会从ISR的follower中选举新的leader。

说下Kafka的ISR机制
可回答：从ISR踢出去之后呢
问过的一些公司：头条，腾讯，祖龙娱乐，虎牙(2021.09)x2 参考答案：
ISR（In-Sync Replicas）：副本同步队列
ISR是Leader维护了一个动态副本同步队列，是和leader保持同步的follower集合，ISR中包括Leader和Follower。当ISR中的follower完成数据的同步之后，leader就会给producer发送ack。如果follower长时间 未向leader同步数据，则该follower将被踢出ISR，加入到OSR（Out-Sync Relipcas），该时间阈值由replica.lag.time.max.ms参数设定。Leader发生故障之后，就会从ISR中选举新的leader。
如果OSR集合中follower副本“追上”了Leader，再加入到ISR中，当Leader发生故障是，只有在ISR集合中 的副本才有资格被选举为leader，而在OSR集合中的副本则没有机会。

Kafka的选举机制
可回答：Kafka的leader选举
问过的一些公司：阿里，顺丰x2，端点数据(2021.07) 参考答案：
在整个系统中，涉及到多出选举，下面从以下三个方面来说明下。
1、控制器（Broker）选举
所谓控制器就是一个Borker，在一个kafka集群中，有多个broker节点，但是它们之间需要选举出一个leader，其他的broker充当follower角色。集群中第一个启动的broker会通过在zookeeper中创建临时节 点 /controller 来让自己成为控制器，其他broker启动时也会在zookeeper中创建临时节点，但是发现节点已经存在，所以它们会收到一个异常，意识到控制器已经存在，那么就会在zookeeper中创建watch 对象，便于它们收到控制器变更的通知。

那么如果控制器由于网络原因与zookeeper断开连接或者异常退出，那么其他broker通过watch收到控制 器变更的通知，就会去尝试创建临时节点 /controller ，如果有一个broker创建成功，那么其他broker 就会收到创建异常通知，也就意味着集群中已经有了控制器，其他broker只需创建watch对象即可。
如果集群中有一个broker发生异常退出了，那么控制器就会检查这个broker是否有分区的副本leader，如 果有那么这个分区就需要一个新的leader，此时控制器就会去遍历其他副本，决定哪一个成为新的leader，同时更新分区的ISR集合。
如果有一个broker加入集群中，那么控制器就会通过Broker ID去判断新加入的broker中是否含有现有分区的副本，如果有，就会从分区副本中去同步数据。
集群中每选举一次控制器，就会通过zookeeper创建一个 controller epoch ，每一个选举都会创建一个更大，包含最新信息的 epoch ，如果有broker收到比这个 epoch 旧的数据，就会忽略它们，kafka也通过这个 epoch 来防止集群产生“脑裂”。
2、分区副本选举机制
在kafka的集群中，会存在着多个主题topic，在每一个topic中，又被划分为多个partition，为了防止数据 不丢失，每一个partition又有多个副本，在整个集群中，总共有三种副本角色：
leader副本：也就是leader主副本，每个分区都有一个leader副本，为了保证数据一致性，所有的生 产者与消费者的请求都会经过该副本来处理。
follower副本：除了首领副本外的其他所有副本都是follower副本，follower副本不处理来自客户端 的任何请求，只负责从leader副本同步数据，保证与首领保持一致。如果leader副本发生崩溃，就 会从这其中选举出一个leader。
优先副本：创建分区时指定的优先leader。如果不指定，则为分区的第一个副本。
follower需要从leader中同步数据，但是由于网络或者其他原因，导致数据阻塞，出现不一致的情况，为 了避免这种情况，follower会向leader发送请求信息，这些请求信息中包含了follower需要数据的偏移量offset，而且这些offset是有序的。
如果有follower向leader发送了请求1，接着发送请求2，请求3，那么再发送请求4，这时就意味着follower已经同步了前三条数据，否则不会发送请求4。leader通过跟踪 每一个follower的offset来判断它们的复制进度。
默认的，如果follower与leader之间超过10s内没有发送请求，或者说没有收到请求数据，此时该follower 就会被认为“不同步副本”。而持续请求的副本就是“同步副本”，当leader发生故障时，只有“同步副本”才 可以被选举为leader。其中的请求超时时间可以通过参数 replica.lag.time.max.ms 参数来配置。
我们希望每个分区的leader可以分布到不同的broker中，尽可能的达到负载均衡，所以会有一个优先leader，如果我们设置参数 auto.leader.rebalance.enable 为true，那么它会检查优先leader是否是真正的leader，如果不是，则会触发选举，让优先leader成为leader。
3、消费者选主
在kafka的消费端，会有一个消费者协调器以及消费组，组协调器 GroupCoordinator 需要为消费组内的消费者选举出一个消费组的leader，那么如何选举的呢？
如果消费组内还没有leader，那么第一个加入消费组的消费者即为消费组的leader，如果某一个时刻
leader消费者由于某些原因退出了消费组，那么就会重新选举leader，如何选举？

1. private val members = new mutable.HashMap[String, MemberMetadata]
2. leaderId = members.keys.headOption
   上面代码是kafka源码中的部分代码，member是一个hashmap的数据结构，key为消费者的
   ，value是元数据信息，那么它会将leaderId选举为Hashmap中的第一个键值对，它和随机基 本没啥区别。
   member_id

Kafka的ISR、OSR和ACK介绍，ACK分别有几种值？
问过的一些公司：快手，ebay 参考答案：
ISR（In-Sync Replicas）：副本同步队列
ISR是Leader维护了一个动态副本同步队列，是和leader保持同步的follower集合。
OSR（Out-Sync Relipcas）：
当ISR中的follower长时间（replica.lag.time.max.ms参数设定）未向leader同步数据，则该follower将被踢 出ISR，加入到OSR。
ACK：producer的消息发送确认机制
ack=0
producer不等待broker的ack，这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经 返回，当broker故障时有可能丢失数据
ack=1
producer等待broker的ack，partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故 障，那么将会丢失数据；
ack=-1
producer等待broker的ack，partition的leader和follower全部落盘成功后才返回ack。但是如果在follower
同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复。

Kafka的工作原理？
可回答：Kafka的工作流程
问过的一些公司：阿里，字节社招，字节(2022.03)，b站，七牛云，创略科技，网易
先来看个简单版本的

Kafka中消息是以topic进行分类的，生产者生产消息，消费者消费消息，都是面向topic的。
topic是逻辑上的概念，而partition是物理上的概念，每个partition对应于一个log文件，该log文件中存储 的就是producer生产的数据。Producer生产的数据会被不断追加到该log文件末端，且每条数据都有自己 的offset。消费者组中的每个消费者，都会实时记录自己消费到了哪个offset，以便出错恢复时，从上次 的位置继续消费。
再来看个详细版本的
关于Kafka的架构就不多说了，前面有相关介绍。
1、发送数据
Producer是生产者，是数据的入口。注意看图中的红色箭头，Producer 在写入数据的时候永远在找
Leader，不会直接将数据写入 Follower！
关于Leader的寻找以及写入流程可以参考下图：

消息写入Leader后，Follower是主动的去找Leader进行同步的！
Producer 采用 Push 模式将数据发布到 Broker，每条消息追加到分区中，顺序写入磁盘，所以保证同一分区内的数据是有序的！
写入示意图如下：

上面说到数据会写入到不同的分区，那 Kafka 为什么要做分区呢？相信大家应该也能猜到，分区的主要目的是：
方便扩展。因为一个Topic 可以有多个Partition，所以我们可以通过扩展机器去轻松的应对日益增长的数据量。
提高并发。以Partition 为读写单位，可以多个消费者同时消费数据，提高了消息的处理效率。
熟悉负载均衡的应该知道，当我们向某个服务器发送请求的时候，服务端可能会对请求做一个负载，将 流量分发到不同的服务器。

那在 Kafka 中，如果某个 Topic 有多个 Partition，Producer 又怎么知道该将数据发往哪个 Partition 呢？
Kafka 中有几个原则：
Partition 在写入的时候可以指定需要写入的Partition，如果有指定，则写入对应的Partition。如果没有指定Partition，但是设置了数据的Key，则会根据Key 的值Hash 出一个Partition。如果既没指定Partition，又没有设置Key，则会轮询选出一个Partition。
保证消息不丢失是一个消息队列中间件的基本保证，那 Producer 在向 Kafka 写入消息的时候，怎么保证消息不丢失呢？
其实上面的写入流程图中有描述出来，那就是通过 ACK 应答机制！在生产者向队列写入数据的时候可以设置参数来确定是否确认 Kafka 接收到数据，这个参数可设置的值为 0、1、all：
a. 代表Producer 往集群发送数据不需要等到集群的返回，不确保消息发送成功。安全性最低但是效率最高。
b. 代表Producer 往集群发送数据只要Leader 应答就可以发送下一条，只确保Leader 发送成功。all 代表Producer 往集群发送数据需要所有的Follower 都完成从Leader 的同步才会发送下一条，确保Leader 发送成功和所有的副本都完成备份。安全性最高，但是效率最低。
最后要注意的是，如果往不存在的 Topic 写数据，能不能写入成功呢？Kafka 会自动创建 Topic，分区和副本的数量根据默认配置都是 1。
2、保存数据
Producer 将数据写入 Kafka 后，集群就需要对数据进行保存了！Kafka 将数据保存在磁盘，可能在我们的一般的认知里，写入磁盘是比较耗时的操作，不适合这种高并发的组件。Kafka 初始会单独开辟一块磁盘空间，顺序写入数据（效率比随机写入高）。

1. Partition结构
   前面说过了每个 Topic 都可以分为一个或多个 Partition，如果你觉得 Topic 比较抽象，那 Partition 就是比较具体的东西了！
   Partition 在服务器上的表现形式就是一个一个的文件夹，每个 Partition 的文件夹下面会有多组 Segment
   文件。
   每组 Segment 文件又包含 .index 文件、.log 文件、.timeindex 文件（早期版本中没有）三个文件。
   Log 文件就是实际存储 Message 的地方，而 Index 和 Timeindex 文件为索引文件，用于检索消息。
   
   如上图，这个 Partition 有三组 Segment 文件，每个 Log 文件的大小是一样的，但是存储的 Message 数量是不一定相等的（每条的 Message 大小不一致）。
   文件的命名是以该 Segment 最小 Offset 来命名的，如 000.index 存储 Offset 为 0~368795 的消息，Kafka 就是利用分段+索引的方式来解决查找效率的问题。
2. Message结构
   上面说到 Log 文件就实际是存储 Message 的地方，我们在 Producer 往 Kafka 写入的也是一条一条的
   Message。
   那存储在 Log 中的 Message 是什么样子的呢？消息主要包含消息体、消息大小、Offset、压缩类型…… 等等！
   我们重点需要知道的是下面三个：
   Offset：Offset 是一个占 8byte 的有序id 号，它可以唯一确定每条消息在Parition 内的位置！ 消息大小：消息大小占用 4byte，用于描述消息的大小。
   消息体：消息体存放的是实际的消息数据（被压缩过），占用的空间根据具体的消息而不一样。
3. 存储策略
   无论消息是否被消费，Kafka 都会保存所有的消息。那对于旧数据有什么删除策略呢？
   基于时间，默认配置是 168 小时（7 天）。基于大小，默认配置是 1073741824。
   需要注意的是，Kafka 读取特定消息的时间复杂度是 O(1)，所以这里删除过期的文件并不会提高 Kafka
   的性能！
   3、消费数据
   消息存储在 Log 文件后，消费者就可以进行消费了。Kafka 采用的是点对点的模式，消费者主动的去Kafka 集群拉取消息，与 Producer 相同的是，消费者在拉取消息的时候也是找 Leader 去拉取。多个消费者可以组成一个消费者组（Consumer Group），每个消费者组都有一个组 id！
   同一个消费组者的消费者可以消费同一 Topic 下不同分区的数据，但是不会组内多个消费者消费同一分区的数据！
   详情如下图：
   
   图示是消费者组内的消费者小于 Partition 数量的情况，所以会出现某个消费者消费多个 Partition 数据的情况，消费的速度也就不及只处理一个 Partition 的消费者的处理速度！
   如果是消费者组的消费者多于 Partition 的数量，那会不会出现多个消费者消费同一个 Partition 的数据呢？

上面已经提到过不会出现这种情况！多出来的消费者不消费任何 Partition 的数据。所以在实际的应用中，建议消费者组的 Consumer 的数量与 Partition 的数量一致！
在保存数据的小节里面，我们聊到了 Partition 划分为多组 Segment，每个 Segment 又包含.log、.index、.timeindex 文件，存放的每条 Message 包含 Offset、消息大小、消息体……
前面多次提到 Segment 和 OGset，查找消息的时候是怎么利用 Segment+OGset 配合查找的呢？
假如现在需要查找一个 Offset 为 368801 的 Message 是什么样的过程呢？我们先看看下面的图：

① 先找到 Offset 的 368801message 所在的 Segment 文件（利用二分法查找），这里找到的就是在第二个 Segment 文件。
② 打开找到的 Segment 中的 .index 文件（也就是 368796.index 文件，该文件起始偏移量为 368796+1。
我们要查找的 Offset 为 368801 的 Message 在该 Index 内的偏移量为 368796+5=368801，所以这里要查找的相对 Offset 为 5）。
由于该文件采用的是稀疏索引的方式存储着相对 Offset 及对应 Message 物理偏移量的关系，所以直接找相对 Offset 为 5 的索引找不到。
这里同样利用二分法查找相对 Offset 小于或者等于指定的相对 Offset 的索引条目中最大的那个相对
Offset，所以找到的是相对 Offset 为 4 的这个索引。
③根据找到的相对 Offset 为 4 的索引确定 Message 存储的物理偏移位置为 256。
打开数据文件，从位置为 256 的那个地方开始顺序扫描直到找到 Offset 为 368801 的那条 Message。
这套机制是建立在 Offset 为有序的基础上，利用 Segment+有序 Offset+稀疏索引+二分查找+顺序查找等多种手段来高效的查找数据！
至此，消费者就能拿到需要处理的数据进行处理了。那每个消费者又是怎么记录自己消费的位置呢？
在早期的版本中，消费者将消费到的 Offset 维护在 Zookeeper 中，Consumer 每间隔一段时间上报一次，这里容易导致重复消费，且性能不好！
在新的版本中消费者消费到的 Offset 已经直接维护在 Kafka 集群的 consumer_offsets 这个 Topic 中。