broker处理获取请求的方式跟处理生产请求的方式很相似。客户端发送请求向broker请求主题分区具有特定偏移量的消息。客户端还可以指定broker最多可以从一个分区中返回多少数据------这个限制十分重要：因为客服端需要为broker返回的数据分配足够内存。如果没有这个限制，broker返回的大量数据有可能耗尽客户端的内存。
请求需要先达到指定的分区首领上，然后客户端通过查询元数据俩确保请求的路由是正确的，首领在收到请求时，它会检查请求是否有效------比如，指定的偏移量不存在，那么broker将返回一个错误。
如果请求的偏移量存在，broker将按照客户端指定的数量上限分区里读取消息，再把消息返回客户端，kafka使用零复制技术向客户端发送消息------也就是说kafka直接把消息从文件（或者说Linux文件系统缓存）里发送到网络通道，而不需要经过任何中间缓冲区。
客户端除了可以设置broker返回数据的上限，也可以设置下限。例如：将下限设置为10kb，这样就好像告诉broker：“等数据有了10kb在把数据发送给我”，在主题消息流量不是很大的情况下，可以减少CPU和网络的开销。
当然也不可能让客户端一直等broker积累数据，在等待了一段时间之后，就可以把可用的数据拿回处理。所以客户端可以定义一个超时时间，告诉broker：“如果你无法在X ms内累积满足需要的数据量，那就把当前的数据返回给我”。
有意思的是，并不是所有保存在分区首领上的数据都可以被客户端读取。大部分客户端只能读取已经被写入所有同步副本的消息（跟随者副本也不行，尽管他们也是消费者---不然复制功能会无法工作）。分区首领知道每个消息会被复制到哪个副本上在消息还没有被写入所有同步副本之前，是不会发送给消费者------尝试获取这些消息的请求会得到null而不是错误
因为还没有足够多副本复制的消息会被认为“不安全”的------如果首领发生崩溃，另一个副本成为新的首领，那么这个消息就会丢失，消费者读取这些信息，就有可能破会一致性
上一篇地址：https://www.imooc.com/article/259760