A fetch request lets a Kafka consumer retrieve records from a partition. It names the partition and the offset where the broker should begin returning messages. Consumers usually delegate partition and offset handling to the Kafka library; console consumers can specify them directly. section 9.1.1
A broker handles a fetch request through a read-oriented data flow:
- Network threads receive the request and place it in the request queue. section 9.2
- I/O threads read batches from the filesystem, although the page cache may satisfy the request without disk access. section 9.2
- The request purgatory can wait for more messages instead of waiting for another broker. section 9.2
- fetch.min.bytes controls the minimum available response size, while fetch.max.wait.ms limits how long the broker waits; defaults are 1 byte and 500 milliseconds. section 9.2
- The response enters the response queue before a network thread sends it back to the consumer. section 9.2
Reading a partition from offset zero
A console consumer can request partition 0 from offset 0 with kafka-console-consumer.sh. The command reads records from products.prices.changelog, producing values such as “coffee pads 10,” “coffee pads 11,” and “coffee pads 12.” In ordinary consumers, the library selects the partition and offset. Consumers start at the latest messages by default; setting auto.offset.reset to earliest starts at the beginning when appropriate. section 9.1.1
Fetch requests also support replication: followers use a special fetch request to copy records from a partition leader and report their current offsets. This keeps them current and eligible to take over when a leader fails. section 5.3
