搞清 Kafka 基本套路

一、概述

 
       一个典型的 Kafka 体系架构包括若干 Producer(生产者)、若干 个Broker(服务代理节点) 、若干 Consumer(消费者) ,以及一个 ZooKeeper 集群。其中 Kafka 用 ZooKeeper 来管理集群元数据、控制器的选举等操作。Producer(生产者) 将消息发送到 Broker, Broker 负责将收到的消息存储到磁盘中,Consumer(消费者)负责从 Broker 订阅并消 费消息。

 
在这里插入图片描述

二、相关术语

 ## Producer

  • Producer (生产者): 发送消息的一方。生产者负责创建消息,然后将其投递到 Kafka 中。该角色将消息发布到 Kafka 的 Topic(主题) 中。Broker 接收到生产者发送的消息后,Broker 将该消息追加到当前用于追加数据的 segment 文件中。生产者发送的消息,存储到一个Partition(分区) 中,生产者也可以指定数据存储的 Partition(分区)。

在这里插入图片描述

  • Kafka 集群包含一个或多个服务器,服务器节点称为 Broker。Broker 可以简单地看作一个独立的 Kafka 服务节点或 Kafka 服务实例。

  • Broker 存储 Topic(主题) 的数据。如果某 Topic 有 N 个Partition(分区),集群有 N 个 Broker,那么每个 Broker 存储该 Topic(主题) 的一个Partition(分区)。

  • 如果某 Topic(主题) 有N个 Partition(分区),集群有 (N+M) 个 Broker,那么其中有 N 个 Broker 存储该 Topic(主题) 的一个 Partition(分区),剩下的 M 个 Broker 不存储该 Topic(主题) 的 Partition(分区) 数据。

  • 如果某 Topic(主题) 有 N 个 Partition(分区),集群中 Broker 数目少于N个,那么一个 Broker 存储该 Topic(主题) 的一个或多个 Partition(分区)。在实际生产环境中,尽量避免这种情况的发生,这种情况容易导致 Kafka 集群数据不均衡。

在这里插入图片描述

  • Consumer (消费者):接收消息的一方。消费者连接到 Kafka 上并接收消息,进而进行相应的业务逻辑处理。消费者从broker中读取数据,可以消费多个Topic(主题) 中的数据。

在这里插入图片描述

  • Kafka 中的消息以 Topic(主题) 为单位进行归类,生产者负责将消息发送到特定的 Topic(发送到 Kafka 集群中的每一条消息都要指定一个 Topic ),而消费者负责订阅 Topic(主题) 并进行消费。
  • Kafka 中的Partition(分区) 可以分布在不同的服务器 broker 上,所以一个 Topic 可以横跨多个 Broker ,以此来提供比单个 Broker 更强大的性能。

在这里插入图片描述

  • Topic 是一个逻辑上的概念,它还可以细分为多个 Partition(分区),一个 Partition 只属于单个Topic,很多时候也会把分区称为主题分区( Topic-Partition )。

  • 同一 Topic 下的不同 Partition(分区) 包含的消息是不同的,Partition(分区) 在存储层面可以看作一个可追加的日志( Log )文件,消息在被追加到分区日志(Log)文件的时候,都会分配一个特定的偏移量( offset )。

  • offset(偏移量) 是消息在分区中的唯一标识, Kafka 通过它来保证消息在分区内的顺序性,不过 offset 并不跨越分区。Kafka 保证的是 Partition 有序而不是 Topic 有序。

 
在这里插入图片描述

       如下图所示,假设某个 Topic 中有 4个 Partition(分区),消息被顺序追加到每个分区日志文件的尾部。 Kafka 中的分区可以分布在不同的服务器 Broker 上。也就是说,一个 Topic 可以横跨多个 Broker ,以此来提供比单个 Broker 更强大的性能。

在这里插入图片描述

在这里插入图片描述

  • 副本(Replica)本质就是一个只能追加写消息的提交日志。Kafka 为分区(Partition)引入了多副本 Replica 机制, 通过增加副本数量可以提升容灾能力。
  • 同一Partition 的不同副本中保存的是相同的消息(在同一时刻,副本之间并非完全一样),副本之间是“一主多从”的关系。
  • leader 副本负责处理读写请求,follower 副本只负责与 leader 副本的消息同步。
  • 副本处于不同的 broker 中,当 leader 副本出现故障时,从 follower 副本中重新选举新的 leader 本对外提供服务。

在这里插入图片描述
 

三、多副本架构

 
       如下图,假设 Kafka 集群中有4个 Broker ,某个Topic 中有 3 个Pritition(分区),且副本因子(即副本个数)也为 3,如此每个分区便有1个 leader 副本和 2个 follower 副本。生产者和消费者只与 leader 副本进行交互,而 follow 副本只负责消息的同步,很多时候 follower 副本中的消息相对 leader 副本而言会有一定的滞后。

 
在这里插入图片描述
 

3.1 多副本术语

 
在这里插入图片描述

  • Partition(分区)中的所有副本统称为 AR ( Assigned Replicas)。

在这里插入图片描述

  • 所有与 leader 副本保持一定程度同步的副本(包括 leader 副本在内)组成 ISR (On-Sync Replicas) ,ISR 集合是 AR 集合中的一个子集。

在这里插入图片描述

  • 与 leader 副本同步滞后过多的副本(不包 leader 副本)组成 OSR (Out-of-Sync Replicas )。

在这里插入图片描述
 
       leader 副本负责维护和跟踪 ISR 集合中所有 follower 副本的滞后状态, follower 副本落后过多或失效时, leader 副本会把它从 ISR 集合中剔除,当 OSR 集合中有 follower 副本 “追上”了 leader 副本时,leader 副本 它从 OSR 集合转移至 ISR 集合

3.2 多副本模式下,写入消息

 
        如下图所示,它代表 1 个日志(Log)文件,这个日志(Log)文件中有9条消息,第一条消息的 offset( LogStartOffset )为0 ,最后 1 条消息的 offset 8。offset 为9 的消息用虚线框表示,代表下一条待写入的消息。日志(Log)文件的 HW 为6,表示消费者(Consumer)只能拉取到 offset 在0 到 5 之间的消息,而offset 等于6 的消息对消费者而言是不可见的。
 
在这里插入图片描述

在这里插入图片描述
 
 
 
 
 
 
 
 
 
.

猜你喜欢

转载自blog.csdn.net/weixin_41922349/article/details/109529944
今日推荐