Kafka架构：
图：Kafka架构图
基本概念：
-
Broker：Kafka集群包含一个或多个服务实例，这些服务实例被称为Broker。是Kafka当中具体处理数据的单元。Kafka支持Broker的水平扩展。一般Broker数据越多，集群的吞吐力就越强。
-
Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。
-
Partition：Kafka将Topic分成一个或多个Partition，每个Partition在物理上对应一个文件夹，该文件下存储这个Partition的所有消息。
-
Producer：负责发布消息到Kafka Broker。
-
Consumer：消息消费者，从Kafka Broker读取消息的客户端。
-
Consumer Group：每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name）。
-
ZooKeeper：kafka与Zookeeper级联，通过Zookeeper管理级联配置，选举Leader。
Kafka Topics：
图；Kafka Topics
每条发布到Kafka的消息都有个类别，这个类别被称为Topic，也可以理解为一个存储消息的队列。例如：天气作为一个Topic，每天的温度消息就可以存储在“天气”这个队列里。数据总数先进先出。后来的数据追加到后面。
Kafka Partition：
图：Kafka Partition
每个Topic都有一个或者多个Partitions构成。每个Partition都是有序且不可变的消息队列。引入Partition机制，保证了Kafka的高吞吐能力。
在每个Partition当中，都会存储一个Log文件，Log文件中记录了所有的消息文件。一个Topic的多个Partition，它分布在不同的Kafka节点上，这样多个客户端包括Producer和Consumer就可以并发的访问不同节点，对同一个Topic进行消息的读取。
图：Partition
-
Topic的Partition数量可以在创建时配置。
-
Partition数据决定了每个Consumer group中并发消费者的最大数据。
-
Consumer group A有两个消费者来读取4个Partition中数据；Consumer group B有四个消费者来读取4个partition中数据。
Kafka Partition offset:
图：Kafka Partition offset
-
任何发布到此Partition的消息都会被直接追加到log文件的尾部。
-
每条消息在文件中的位置称为offset（偏移量），offset是一个long型数字，它唯一标记一条消息。消费者通过（offset、partition、topic）跟踪记录。
-
Kafka不支持消息的随机读取。
Kafak Partition Replicas（副本）:
图：副本机制
-
副本以分区为单位。每个分区都有各自的主副本。
-
可以通过配置文件，配置副本的个数。
-
一个Kafka集群中，各个节点可能互为Leader和Follower。
-
主副本叫做Leader，从副本叫做Follower，处于同步状态的副本叫做In-Sync Replicas（ISR）。
-
如果Leader失效，那么将会有其他的Follower来接管成为新的Leader。如果由于Follower自身的原因，比如网络原因导致同步落后太多，那么当Leader失效后，就不会将这个Follower选为leader。
-
由于Leader的Server承载了全部的请求压力，因此从集群的整体考虑，Kafka会将Leader均衡的分散在每个实例上，来保持整体稳定。
-
Follower通过拉取的方式从Leader中同步数据。消费者和生产这都是从Leader中读取数据，不与Follower交互。
主副本和从副本的数据同步：
图：主副本和从副本的数据同步
从Partition的Leader复制数据到Follower，需要一个线程，实际上，复制数据的操作，是Follower主动从Leader上批量拉取数据，这就极大的提高了Kafka的吞吐量。Follower复制数据的线程叫做ReplicaFetcher Thread，而Kafka的Producer和Consumer只与Leader进行交互，不会与Follower进行交互。
Kafka中每个Broker启动的时候，都会创建一个副本管理服务ReplicaManager，该服务负责维护ReplicaFether Thread与其他Broker链路连接关系。该服务中存在的Follower Partition对应的Leader Partition会分布在不同的Broker上，这些Broker创建相同数量的ReplicaFether Thread，同步对应Partition数据。Kafka中Partition间复制数据，是由Follower主动从Leader拉消息的。Follower每次读取消息都会更新HW状态，用于记录当前最新消息的标识。每当Follower的Partition发生变化而影响Leader所在的Broker时，ReplicaManager就会新建或者销毁相对应的ReplicaFether Thread。
Kafka Logs：
为了使得Kafka的吞吐率可以线性提高，物理上把Topic分成一个或多个Partition，每个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索性文件。Kafka把Topic中一个Partition大文件分成多个小文件段通过多个小文件段，就容易定期清除或删除已经消费完的文件，减少磁盘占用。
Kafka的存储布局非常简单，Topic的每个分区对应一个逻辑日志，物理上一个日志为相同大小的一个分段文件。每次Producer发布一个消息到一个分区的时候，代理就将这些数据追加到最后一个段文件当中。当发布的消息数量达到消息设定的阈值，或者经过一定的时间后，段文件就会真正的写到磁盘当中。在写入完成以后，消息就会公开给Consumer。
同一个Topic下有不同的分区，每个分区会划分为多个文件，只有一个当前文件在写，其他文件是只读的。当写满一个文件（即达到某个设定的值）Kafka会新建一个空文件继续来写。而老文件切换为只读。
文件的命名以起始的偏移量来进行命名。Segment Files由两大部分组成，分别为Index file和data file，此两个文件一一对应成对出现。后缀 .index 和 .log 就分别表示为Segment的索引文件和数据文件。Segment文件的命名规则是：Partition全局的第一个Segment从0开始，后续每个segment文件为上一个全局Partition的最大offset，这个数据时64位的long型数据。如果没有数据就用0进行填充。通常把日志文件默认为1G，当达到1G就会创建新的Log文件和index文件。如果设置的参数过小，会产生大量的log文件和index文件，系统在启动的时候就需要加载大量的index到内存，占用大量的句柄。如果设置的太大，分段文件又比较少，不利于快速的查找。Kafka就是通过索引实现快速的定位message。
图：索引文件
-
通过索引信息可以快速定位message。
-
通过将index元数据全部映射到memory，可以避免segment file的index数据IO磁盘操作。
-
通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小。
-
稀疏存储：将原来完整的数据，只间隔的选择多条数据进行存储。
Kafka Log Cleanup:
日志的清理方式有两种：delete和compact。
删除的阈值有两种：过期的时间和分区内总日志大小。
删除
图：日志清理方式–compact
compact操作是保存每个消息的最新value值。消息时顺序存储的，offset大的为最新的数据。
Kafka数据可靠性：
小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）
知道该从何学起的朋友，同时减轻大家的负担。**
[外链图片转存中…(img-UL1EOdGc-1710830061352)]
[外链图片转存中…(img-LB7IQvYs-1710830061353)]
[外链图片转存中…(img-skwHf8oe-1710830061354)]
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）
[外链图片转存中…(img-zIE30uNO-1710830061355)]
-
-
-
-