这是我参与「第三届青训营 -后端场」笔记创作活动的第4篇笔记
Kafka架构
如下图所示，Kafka在实际应用场景中通常搭配ZooKeeper一起使用，ZooKeeper负责存储集群元信息，包块分区分配信息，消费者组的消费位置信息等。
整个宏观架构包括了上层的ZooKeeper，消费者，Broker节点构成的集群、消费者组。
Kafka的高吞吐
消息的生命历程
消息模型的思考
传统的消息模型如下，生产者每产生一条消息待到Broker返回成功再生产下一条消息的话，那Kafka想要实现实现高吞吐就是痴人说梦了……
批量发送
因此，实现高吞吐必须采取特殊手段，比如下图所示的生产者批量生产多条消息，一次性发给Broker
那问题来了，如果批量产生的消息量又太多了，网络带宽承受不住了呢？
Kafka的解决方案是采用压缩大法！压缩大法好呀，其实在计算机领域的诸多场景都有涉及到压缩算法，譬如音视频领域，大文件存储领域等，只要压缩后不会损坏数据且能够比较容易地还原数据，那采用压缩算法是会有帮助的！
- Kafka支持了很多压缩算法，诸如Snappy、Gzip、LZ4、ZSTD等，其中更推荐ZSTD，因为它的压缩率更可观
那Broker成功收到压缩后的消息后，便会想办法存到存储介质中了
Broker的消息文件结构
那看到这里不禁会思考，Broker又是怎么去存储这些消息的呢？我们不妨先认识一下Broker的消息文件结构：
分析一下上述文件结构，其实答案就在图中。各个分区中的副本，本质上来说都是数据，它们都会封装为日志的形式去存储，具体来说就是Log文件，Log文件包含了很多字段，后面通过Log文件就可以找到真实文件具体位置的映射，也就能找到所存放的数据啦
获取消息
说完如何存，接下来聊聊如何取。Consumer通过发送FetchRequest请求消息数据，Broker拿到这个request后会根据里面指定的Offset去对应上文谈到的Log文件去找到相应的数据，按照时间窗口和消息大小窗口送给Consumer。
