Broker（代理）：一个独立的Kafka实例。多个Kafka实例（broker）组成一个Kafka集群。
Topic（主题）：同类消息的集合是逻辑概念。生产者按主题生产消息，消费者按主题消费消息。
Partition（分区）：Partition是物理概念，将同一Topic分布到多个Broker。例如上图Topic A被分成三个分区（Part0、Part1、Part2），分布在三个Broker。Kafka多分区可以提升消息消费速度（多消费者消费同一主题消息）。
Replica（副本）：Leader和Follower的集合，一个Topic的每个分区都有若干副本（一个Leader，多个Follower）。多副本可以实现数据备份，提高Kafka的可用性。
Leader（主副本）：每个分区多个副本的主副本，生产者和消费者操作的对象。
Follower（从副本）：每个分区多个副本的从副本，实时从主副本同步数据，当Leader发生故障某个Follower成为新的Leader对外提供服务。
1.2.Kafka存储机制
Kafka的数据最终都会存储到磁盘中，最直观的感受就是一个个文件。这些文件是怎么存储和管理的呢。
为了提升并发，Kafka会将同一话题（Topic）的消息分布在不同的分区（Partition）上。
其中每个分区会对应一个log文件，在log文件过大时，会存在数据定位效率低下的问题。为了解决这个问题Kafka采用了分片和索引机制，将每个分区（partition）分为多个segment，每个segement分为.index文件、.log文件和.timeindex文件。
其中segement是逻辑存在的，具有相同文件名前缀的XXX.index、XXX.log、XXX.timeindex为同一个segment。其中文件前缀为同一个segment中所有消息的最小offset。例如00000000.index对应segment中最小的offset是0，00004096.index对应segment中最小的offset是4096。
消息的存储方式了解了，如何通过offset找到消息？
我们下面的分析不考虑.timeindex。对于offset=666，我们分析一下对应消息查找过程。
1.首先根据offset去定位对应的Segment即XXX.index、XXX.log
2.然后到根据二分查找找到索引文件XXX.index中offset对应稀疏索引位置
3.根据.index文件中的稀疏索引找到的position查找对应的.log数据，找到对用position（物理存储位置）然后逐个遍历records中的消息找到对应offset
index为稀疏索引，每往log文件加入4kb的数据，会往index文件写入一条索引。可以通过log.index.interval.bytes控制。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
