Kafka是什么

简介

kafka是一款消息引擎系统,它不单单可以用做消息队列,还可以支持大数据数据流式传输.

集群架构

kafka集群架构

传输协议

点对点传输

可以成为消息队列,即A发送只能由B接收.

发布/订阅模型

生产者生产数据,发送到topic,消费者接收数据模型.

为什么要用Kafka

基于阿里的三连问,为什么要用?解决了哪些问题?能带来哪些好处?

Kafka实现的功能就是削峰填谷,见闻识意,系统中的流量总会是不规则的,有高峰期,低谷期.kafka做解决的就是将流量维持平衡,保护应用层.

就像黄河每年洪水或者干旱的时候,总会引发大量人口死亡,明朝有位官员就很好的解决了这个问题,在黄河旁边挖一个大坑,洪水的时候,引流到大坑里面,等到干旱的时候,在进行放水.有效的解决了自然灾害带来的人员损坏.

组成

Broker

Kafka集群是由Broker服务进程组成,Broker来处理客户端的请求.

一般每台机器一个Broker,当然也可以多个,但不建议,一旦宕机,多机器部署下,kafka也依然能够提供服务.

broker节点在启动时,注册到zk,zk新增节点路径:/brokers/ids

Topic

主题,是发布的对象,通常是一系列业务消息的聚合.

topic信息在zk维护,节点路径:/brokers/topics/my-topic/Partitions/1

producer

生产者,生产数据.

consumer

消费者,消费数据.1个消费者可以消费多个分区的数据.

consumer group

消费者组,对于一个主题的数据,同一个消费者组里面的消费者会共同消费其数据,增加吞吐量.

不同的的消费者组之间,都会收到同一个topic的数据.

当同一个消费者组里面的一个消费者挂掉后,会进行rebalance,重新分配分区与消费者关系.

通过消费者组来实现了点对点模型和发布订阅模型.

partition

分区,实现扩展性的一种手段.同一个topic的消息,会默认分成50个,存储在不同的broker中.同时为每个分区提供副本进行数据备份.一个分区最多只能让一个消费者消费.

面试环节:3个分区,4个消费者.允许吗?

这个时候,会有1个消费者处于空闲状态.

replication

副本机制,实现高可用的一种手段.分为leader副本和follower副本,和mysql不同的是,生产者的写入和消费者的消费,都是和leader副本交互的.follower副本做的是将leader副本的数据同步过来.

比如 MongoDB 和 Elasticsearch 中的 Sharding,HBase 中的 Region,其实它们都是分区的一种表现.

log segment

分区数据持久化到磁盘的表现,每条消息是以二进制的格式持久化到磁盘.

每条消息都是以追加的形式进行的写到磁盘,因此避免了磁盘的随机IO,这也是高吞吐的一种方式.

对于写入的数据,当一个log文件写满之后,kafka自动切分一个日志段,并将老的日志段封存,同时还会有定时任务自动删除过期的数据.

至此我们能够完整地串联起 Kafka 的三层消息架构:

  • 第一层是主题层,每个主题可以配置 M 个分区,而每个分区又可以设置 N 个副本.

  • 第二层是分区层,每个分区的 N 个副本中只能有一个充当领导者角色,对外提供服务;其他 N-1 个副本是追随者副本,只是提供数据冗余之用.

  • 第三层是消息层,分区中包含若干条消息,每条消息的位移从 0 开始,依次递增.

  • 最后,客户端程序只能与分区的领导者副本进行交互.

消息位移Offset

表示消息在分区中的位置,是一个不变且递增的值.

消费者位移

Consumer Offset,表示消息消费的进度,每个消费者都有自己的消费者位移.这个保存在了消费者位移主题里面.

Coordinator

协调者,所谓协调者,它专门为 Consumer Group 服务,负责为 Group 执行 Rebalance 以及提供位移管理和组成员管理等。

具体来讲,Consumer 端应用程序在提交位移时,其实是向 Coordinator 所在的 Broker 提交位移。同样地,当 Consumer 应用启动时,也是向 Coordinator 所在的 Broker 发送各种请求,然后由 Coordinator 负责执行消费者组的注册、成员管理记录等元数据管理操作。

所有 Broker 在启动时,都会创建和开启相应的 Coordinator 组件。也就是说,所有 Broker 都有各自的 Coordinator 组件。那么,Consumer Group 如何确定为它服务的 Coordinator 在哪台 Broker 上呢?答案就在我们之前说过的 Kafka 内部位移主题 __consumer_offsets 身上。

目前,Kafka 为某个 Consumer Group 确定 Coordinator 所在的 Broker 的算法有 2 个步骤。

第 1 步:确定由位移主题的哪个分区来保存该 Group 数据:partitionId=Math.abs(groupId.hashCode() % offsetsTopicPartitionCount)。

第 2 步:找出该分区 Leader 副本所在的 Broker,该 Broker 即为对应的 Coordinator。

LAG

滞后程度,比如:生产了100条数据,消费了80条,lag=20.

Lead

消费者最新消息的位移和当前分区第一条位移的差值.如果lead接近0时,就要注意消息快过期删除了.

总结

Last updated

Was this helpful?