上一期讲解了什么是消息队列，主流产品的对比，以及Kafka的基本概念

数据复制

一条消息

Producer->Broker->Consumer

在生产关系中，如果Producer发送一条消息，等到Broker成功后再发一条会有什么问题？

我们可以对消息进行一个Batch，把多个消息结合起来，提高吞吐，但是带宽可能不够用，我们可以通过压缩解决这个问题，通过压缩，减少信息大小。

Broker如何存储到磁盘？

为了提高写入磁盘的效率Kaska使用了顺序写，在某个扇区里面写，不需要频繁转动磁头，提高了我们的读写速度。

Broker如何找到消息？

Consumer通过发送FetchRequest请求消息数据，Broker会将指定的Offset处的消息，按照时间窗口和消息大小窗口发送给Consumer，寻找数据这个细节是如何做到的？（Broker拿到FetchRequest之后会做一些什么事情）

这里用到了Broker索引文件的概念，根据目标offset进行查找，二分找到小于目标offset的最大文件。

二分找到小于目标offset的最大索引位置

对于时间索引，二分查找小于目标时间戳最大的索引位置，再通过寻找offset的方式找到最终数据

消息接受端，如何解决在Partition在ConsumerGroup中的分配问题。

通过手动分配，哪一个Consumer消费哪一个，Partiiton完全由业务来决定

但是不能用自动去容灾

总结一下提到的一些关于可以帮助Kafka提高吞吐量或者稳定性的功能

Producer：批量发送，数据压缩

Broker：顺序写，消息索引，零拷贝

Consumer：Ralance

关于重启

关于Kafka的问题总结