a6f217b8ec592a4af7cda4593bc91240.png

Kafka各组件说明

a5d7a70e1d4530b1d0b281110b106011.png

1.Broker

每个kafka server称为一个Broker,多个borker组成 Kafka Cluster。

一个机器上可以部署一个或者多个Broker,这多个Broker连接到相同的ZooKeeper就组成了Kafka集群。

27c25e7b26671a64fc676437780776f8.jpeg

2.Topic

Kafka是一个发布订阅消息系统,它的逻辑结构如下:

c063e34aa15d9a4f0fd56b747c9b18a8.jpeg

Topic 就是消息类别名,一个topic中通常放置一类消息。每个topic都有一个或者多个订阅者,也就是消息的消费者consumer。

Producer将消息推送到topic,由订阅该topic的consumer从topic中拉取消息。

3.Topic 与 Broker

一个Broker上可以创建一个或者多个Topic,同一个topic可以在同一集群下的多个Broker中分布。

140dcff38e0bd3d57724c09a35a87ba7.jpeg

4. Partition log

Kafka会为每个topic维护了多个分区(partition),每个分区会映射到一个逻辑的日志(log)文件:

b08635d0d5be64b2d15b782fc0ca1418.jpeg

  • 每当一个message被发布到一个topic上的一个partition,broker应会将该message追加到这个逻辑log文件的最后一个segment上。这些segments 会被flush到磁盘上,Flush时可以按照时间来进行,也可以按照message 数来执行。

  • 每个partition都是一个有序的、不可变的结构化的提交日志记录的序列。在每个partition中每一条日志记录都会被分配一个序号,通常称为offset,offset在partition内是唯一的。论点逻辑文件会被化分为多个文件segment(每个segment的大小一样的)。

  • Broker集群将会保留所有已发布的message records,不管这些消息是否已被消费。保留时间依赖于一个可配的保留周期。例如:如果设置了保留策略是2day,那么每一条消息发布两天内是被保留的,在这个2day的保留时间内,消息是可以被消费的。过期后不再保留。

27ddde0b13cacbc9e413ac7d0a714216.jpeg

5.Partition distribution

日志分区是分布式的存在于一个kafka集群的多个broker上。每个partition会被复制多份存在于不同的broker上。这样做是为了容灾。具体会复制几份,会复制到哪些broker上,都是可以配置的。经过相关的复制策略后,每个topic在每个broker上会驻留一到多个partition。如图:

9a463f9d1d1d5ee6638edc9d5472dfad.jpeg

对于同一个partition,它所在任何一个broker,都有能扮演两种角色:leader、follower。看上面的例子,红色的代表是一个leader。

对于topic1的4个partition:

Part 1的leader是broker1,followers是broker2\3。Part2的leader是broker2,followers是broker1\4。Part3的leader是broker3,followers是broker1\3。Part4的leader是broker4,followers是broker2\3。

对于topic2的3个partition:

Part1的leader是broker1,followers是broker2。Part2的leader是broker2,followers是broker3。Part3的leader是broker3,followers是broker4。

对于topic2的4个partition:

Part 1的leader是broker4,followers是broker1\2\3。Part2的leader是broker2,followers是broker1\3\4。Part3的leader是broker3,followers是broker1\2\4。Part4的leader是broker1,followers是broker2\3\4。

下面是一个真实的例子:

af5a17a54b09f30d41f9995636154d84.jpeg

图中的partition 0 的leader是broker 2,它有3个replicas:2,1,3。

In-Sync Replica:在同步中,也就是有哪些broker正处理同步中。partition 0的ISR是2,1,3,说明了3个replica都是正常状态。如果有一个broker down,那么它就不会在ISR中出现。

之后把broker1停止后:

f40a047bf119977d95aeccba88041805.jpeg

每个partition的Leader的用于处理到该partition的读写请求的,每个partition的followers是用于异步的从它的leader中复制数据的。

Kafka会动态维护一个与Leader保持一致的同步副本(in-sync replicas (ISR))集合,并且会将最新的同步副本(ISR )集合持久化到zookeeper。如果leader出现问题了,就会从该partition的followers中选举一个作为新的leader。

所以呢,在一个kafka集群中,每个broker通常会扮演两个角色:在一个partition中扮演leader,在其它的partition中扮演followers。Leader是最繁忙的,要处理读写请求。这样将leader均分到不同的broker上,目的自然是要确保负载均衡。

6.Producer

Producer作为消息的生产者,在生产完消息后需要将消息投送到指定的目的地(某个topic的某个partition),Producer可以根据指定选择partition的算法或者是随机方式来选择发布消息到哪个partition。

7.Consumer

  • 在Kafka中,同样有consumer group的概念,它是逻辑上将一些consumer分组。因为每个kafka consumer是一个进程,所以一个consumer group中的consumers将可能是由分布在不同机器上的不同的进程组成的。

  • Topic中的每一条消息可以被多个consumer group消费,然而每个consumer group内只能有一个consumer来消费该消息。所以,如果想要一条消息被多个consumer消费,那么这些consumer就必须是在不同的consumer group中。

  • 每个consumer可以订阅多个topic。

  • 每个consumer会保留它读取到某个partition的offset,而consumer 是通过zookeeper来保留offset的。


34c38e86d0f3735ff64a3ebabf979767.png

架构图

c21eebb640a95166b691fb67376aaa87.png

对上述各组件介绍后,现在就应该可以很容易的理解Kafka的架构图:

573cf4b64a286d6416067fdb290b48e2.jpeg

在 0.8版本之后,consumer 不会再与zookeeper直接通信了,所以该架构图也应该有所调整了:

c02a57d59828562ecd389224a6944015.jpeg

作者:Natasha_

来源:juejin.cn/post/6890398563004579854

版权申明:内容来源网络,仅供分享学习,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢!

a0f68499b177f9079582b70b22ce4f6c.png

Logo

为开发者提供学习成长、分享交流、生态实践、资源工具等服务,帮助开发者快速成长。

更多推荐