サーバー側の処理要求fetchRequest

1はじめに

消費者のセクションでは、我々は知っている、中のpollOnceの消費者でsendFetches（）メソッドを（）を呼び出します

このセクションでは、サーバはfetchRequest、FetchRequest KafkaApis.handleFetchRequestは、サーバ機能によって処理されたリクエストを処理する方法について説明し、FetchReuqest重要な分野は、RequestInfoを次のとおりです。マップ[TopicAndPartition、PartitionFetchInfo]）

それは要求を取得するために、フォーカスオフセットとのFetchSizeフェッチTopicAndParititonの実装である、です。

彼らの治療のためのブローカーは、認証に区別をしましたが、実際には、同期からメインカフカがFetchRequest、プロセスと同様の消費者のプルメッセージによって行われ、、）（handleFetchRequestで対処しているのは、特定のFetchRequestを見てみましょうプロセス：

2 handleFetchRequest（）プロセス

次のようにソース機能は次のとおりです。

関数の先頭で

この条件が満たされているかReadMessageSetsは最初の読み出し電流のログ読み取り可能なデータに実行、データの量は、その後、直接後で返し、フェッチします。次いで、要求は同期フォロワからのものであるかどうかを判定し、もしそうであれば、のフォロワをオフセットrecordFollowerLogEndOffsetsレコードと呼ぶことにする。フェッチ

この関数は、ReplicaManager.updateReplicaLEOAndPartitionHWを呼び出します。

コード実行の量は少ないですが、インパクトrecordFollowerLogEndOffsetsは素晴らしいもたらしたものの：

Lメッセージをフェッチオフセットリードレオフォロワを表すので、レプリカとlogEndOffsetUpdateTimeMsValue logEndOffsetMetadata変数が更新されます。
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 返回结果，满足条件的话立马返回，否则的话，通过延迟操作，延迟返回结果。