Server端处理fetchRequest请求

1前言

在consumer章节，我们知道，在consumer的pollOnce()中调用sendFetches()方法，

本节主要介绍服务端处理fetchRequest请求的过程，FetchRequest由服务端函数KafkaApis.handleFetchRequest处理， FetchReuqest中重要的字段是requestInfo: Map[TopicAndPartition, PartitionFetchInfo])

即对于Fetch请求来说，关注点是TopicAndParititon执行Fetch的offset以及FetchSize。

其实Kafka的主从同步也是通过FetchRequest来完成，与consumer拉取消息的过程相似,都在handleFetchRequest()中进行处理，不过broker对他们的处理在身份验证上做了区分，下面我们看具体的FetchRequest处理过程:

2 handleFetchRequest()处理过程

该函数的源码如下：

在函数的开头部分

先是执行readMessageSets读取了log上当前可读的数据，这个数据量如果已经满足了Fetch的条件的话，后面会直接返回。之后会判断Fetch是否是来自于Follower的同步请求，如果是，则会调用recordFollowerLogEndOffsets记录Follower的offset。

该函数会调用ReplicaManager.updateReplicaLEOAndPartitionHW:

虽然执行的代码量很少，但recordFollowerLogEndOffsets带来的影响很大：

l 根据Fetch读到的message的offset代表了follower的leo，所以replica中的logEndOffsetMetadata和logEndOffsetUpdateTimeMsValue变量会更新；
l replicaManager.maybeShrinkIsr函数作为一个定期任务，会根据replica的logEndOffsetMetadata和logEndOffsetUpdateTimeMsValue变量清理ISR，将leo落后太多或者长时间没更新的replica从ISR中踢出；
l replica的leo更新，如果满足条件leo > leaderHw，则该replica有可能会成为ISR中的一员，并更新zk中的ISR记录。
l 如果replica本来就是ISR，leo更新意味着leaderHw也有可能会发生变化。
l 在requiredAcks>1或者=-1时，DelayedProduce请求所需条件与replica是否满足leo>requiredOffset有关，所以需要调用producerRequestPurgatory.update；
l 如果FetchRequest不想等待，或者已经读到了足够的数据，FetchRequest会直接使用已经读到的数据进行返回。
l 否则，会执行如下代码：

这里和ProducerRequest一样，将FetchRequest组装为DelayedFetch并加入到Purgatory中。

如果不是来自replica的请求，调用ReplicaManager.fetchMessages()方法，从本地副本中获取数据，并等待足够多的数据进行返回，其中传入的responseCallback方法在超时或者是满足fetch条件时将会被调用，将结果返回给客户端。

整体来说，分为以下几步：

l readFromLocalLog()：调用该方法，从本地日志拉取相应的数据；
l 判断 Fetch 请求来源，如果来自副本同步，那么更新该副本的 the end offset 记录，如果该副本不在 isr 中，并判断是否需要更新 isr；
l 返回结果，满足条件的话立马返回，否则的话，通过延迟操作，延迟返回结果。