Kafka基础架构

kafka概述

Kafka是LinkedIn开源的分布式发布-订阅消息系统由Scala语言编写,目前归属于Apache定级项目。Kafka它提供了类似于JMS的特性,但是在设计实现上完全不同,结合JMS中的两种模式,可以有多个消费者主动拉取数据,在JMS中只有点对点模式才有消费者主动拉取数据。主要特点是基于Pull的模式来处理消息消费,追求高吞吐量,主要应用于 大数据实时处理领域。

JMS:JMS(JAVA Message Service,Java消息服务)API是一个消息服务的标准或者说是规范,类似于JDBC(Java Database Connectivity)允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。它使分布式通信耦合度更低,消息服务更加可靠以及异步性。

Kafka基础架构

Kafka基本概念

网络拓扑图

Kafka基本概念

名词解释

Producer :消息生产者,就是向 kafka broker 发消息的客户端

Consumer :消息消费者,向 kafka broker 取消息的客户端

Consumer Group (CG):消费者组,由多个 consumer 组成。消费者组内每个消费者负 责消费不同分区的数据,一个分区只能由一个组内消费者消费;消费者组之间互不影响。所 有的消费者都属于某个消费者组,即消费者组是逻辑上的一个订阅者。

Broker :一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。

Topic :可以理解为一个队列,生产者和消费者面向的都是一个 topic;

Partition:为了实现扩展性,一个非常大的 topic 可以分布到多个 broker(即服务器)上,一个 topic 可以分为多个 partition,每个 partition 是一个有序的队列;

Replica:副本,为保证集群中的某个节点发生故障时,该节点上的 partition 数据不丢失,且 kafka 仍然能够继续工作,kafka 提供了副本机制,一个 topic 的每个分区都有若干个副本, 一个 leader 和若干个 follower。

leader:每个分区多个副本的“主”,生产者发送数据的对象,以及消费者消费数据的对象都是 leader。

follower:每个分区多个副本中的“从”,实时从 leader 中同步数据,保持和 leader 数据的同步。leader 发生故障时,某个 follower 会成为新的 follower。

概念一:生产者与消费者

Kafka基本概念

对于 Kafka 来说客户端有两种基本类型:

  1. 生产者(Producer)
  2. 消费者(Consumer)

除此之外,还有用来做数据集成的 Kafka Connect API 和流式处理的 Kafka Streams 等高阶客户端,但这些高阶客户端底层仍然是生产者和消费者API,它们只不过是在上层做了封装。

这很容易理解,生产者(也称为发布者)创建消息,而消费者(也称为订阅者)负责消费or读取消息。

概念二:主题(Topic)与分区(Partition)

Kafka基本概念

在 Kafka 中,消息以主题(Topic)来分类,每一个主题都对应一个 「消息队列」,这有点儿类似于数据库中的表。但是如果我们把所有同类的消息都塞入到一个“中心”队列中,势必缺少可伸缩性,无论是生产者/消费者数目的增加,还是消息数量的增加,都可能耗尽系统的性能或存储。

我们使用一个生活中的例子来说明:现在 A 城市生产的某商品需要运输到 B 城市,走的是公路,那么单通道的高速公路不论是在「A 城市商品增多」还是「现在 C 城市也要往 B 城市运输东西」这样的情况下都会出现「吞吐量不足」的问题。所以我们现在引入分区(Partition)的概念,类似“允许多修几条道”的方式对我们的主题完成了水平扩展。

概念三:Broker 和集群(Cluster)

Broker的作用:

  • 接收生产者的消息
  • 设置偏移量
  • 持久化消息到磁盘
  • 为消费者提供服务

一个 Kafka 服务器也称为 Broker,它接受生产者发送的消息并存入磁盘;Broker 同时服务消费者拉取分区消息的请求,返回目前已经提交的消息。使用特定的机器硬件,一个 Broker 每秒可以处理成千上万的分区和百万量级的消息。(现在动不动就百万量级..我特地去查了一把,好像确实集群的情况下吞吐量挺高的..嗯..)

若干个 Broker 组成一个集群(Cluster),其中集群内某个 Broker 会成为集群控制器(Cluster Controller),它负责管理集群,包括分配分区到 Broker、监控 Broker 故障等。在集群内,一个分区由一个 Broker 负责,这个 Broker 也称为这个分区的 Leader;当然一个分区可以被复制到多个 Broker 上来实现冗余,这样当存在 Broker 故障时可以将其分区重新分配到其他 Broker 来负责。

当我们启用Kafka的复制机制时,此时会发生分区复制。假设首领分区所在的Broker1挂了,Broker2的分区就会接管领导权,其他消费者和生产则会重新连接到新的Broker2上。

下图是一个样例:

Kafka基本概念

注意:

Kafka拥有保留消息机制,在一定期限内Kafka会保留消息。消息被消费者消费后,消息任然会进行保留,不像其他MQ一样会进行删除。

保留机制:每一个主题都可以设置自己的保留策略

​ 1.保留一定时间

​ 2.保留一定大小

​Kafka 的一个关键性质是日志保留(retention),我们可以配置主题的消息保留策略,譬如只保留一段时间的日志或者只保留特定大小的日志。当超过这些限制时,老的消息会被删除。我们也可以针对某个主题单独设置消息过期策略,这样对于不同应用可以实现个性化。

酷客网相关文章:

赞(0)

评论 抢沙发

评论前必须登录!