kafka(一):kafka架构

3 篇文章 0 订阅

kafka是什么?

  Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications.
  官网对其介绍是分布式流处理平台。

什么是流式数据

  一个网站的数据来源主要分为用户行为产生和系统数据。用户行为数据是不断产生的,例如用户访问了哪个页面,购买了哪件商品,什么时候登录登出,这些数据在电商平台都是用来分析用户行为很重要的数据。这些不断增长的数据就是流式数据。这些流式数据往往增长较快,且量大,且需要大数据分析。领英就是为了解决大量的流式数据才造出了kafka这个著名的轮子。

kafka的定位:

  • 消息中间件
  • 消息引擎
  • 分布式实时流处理平台。

使用场景

  • 大数据领域:网站行为分析、日志聚合、应用监控、流式数据处理、在线和离线数据分析等领域。
  • 数据集成:将消息导入MaxCompute、OSS、RDS、Hadoop、HBase等离线数据仓库。
  • 流计算集成:与StreamComputer、E_MapReduce、Spark、Storm等流计算引擎集成。
    在这里插入图片描述

kafka架构

我们先来看看下面的知识点后,来了解下kafka消息的流向。

broker

在这里插入图片描述

  • message:消息,是消息中间件通信的基本单位。
  • broker:消息缓存点。就像股票经纪人一样,broker收到消息后存储起来,等待消费者消费。
  • producer:消息生产者。producer向broker发送消息。
  • consumer:消息消费者。从broker中消费消息。

  borker就是kafka部署的一台实例机器。这台机器就存储着生产者生产的消息数据。但是producer可能是多个,每个producer会发送不同类型的消息。这些消息到达了broker怎么进行取分呢?这时就有一引入个topic的概念,topic类似于RibbitMq中的queue,用来取分不同业务类型的消息。我们来看下topic:

topic

在这里插入图片描述
  一个broker可以有多个topic接收消息,一个topic可以接收多个producer生产的消息,也可以被多个消费者消费。但是建议一个topic只存储一类业务消息。
  当一个topic对应多个producer和多个consumer的时,且消息越来越多的时候,单个topic内单个文件存储势必会有性能问题,这时引入partition的概念,就是将topic内的消息分为多个分区(文件)存储消息。

partition及consumer group

在这里插入图片描述
在这里有一个消费者组(consumer group)的划分。每个消费者组由多个消费者组成,一个消费者组可以消费多个topic内的消息,但是一个partition不能被一个消费者组内多个消费者消费。
结合一个生活中的例子:
  我们在学校里上课,老师在讲台上讲课传授知识,学生坐在座位上吸收老师讲的知识点,这里假如坐在座位上的同学才能学习,一个座位只能坐一个学生。这个场景映射到kafka:教室就是topic,座位是partition(这里有个点需要注意,就是在kafka里面,消息是分发到partition里,和讲课不太一样),老师则是producer,老师讲的知识就是message,学生则是consumer。在大学里,一个教室可以有多个班级使用,不同的班级都可以来上课,consumer group就是班级。上课开始,一班来上课,先来的学生都找到了座位做下了,如果座位坐满后,再来的学生就只能站着了,坐着的同学都学习到了知识,站着的同学啥都没学到。如果座位没坐满,则学生可以躺在座位上上课(哈哈,很奇怪,但存在)。
  kafka里当消费组里的consumer数量>topic里partition数量时,多的消费者则没有partition可以消费。当consumer数量<topic里partition数量时,就会有一个消费者消费多个partition的情况。新的消费组来消费时可以重新消费消息。
  单个broker会存在高可用问题,当单broker挂掉了,会导致消息丢失。所以使用备份机制来搭建kafka集群来保证高可用性。

架构图

下面我们来看看kafka集群的架构。
在这里插入图片描述  kafka集群会有多个borker来存储消息,但是每个partition只会有一个master进行写消息。其它的从节点会同步主节点的消息,能被consumer消费。图中红色标记的partition就是主节点。每个topic的主节点分区都是交由zookeeper进行选举的。具体的选举策略会在zookeeper里面介绍。
上图解析:

  • 3台broker。两个producer:producer0和producer1。两个topic:topic0和topic1。
  • topic1只有一个分区partition0。topic0有两个分区partition0和partition1,红色字的为主分区,黑色字的为从分区。只有主partition才能提供消息的读写功能,这样的设计主要是为了避免保证数据一致性带来的可用性下降的问题,因为从follower消费消息,肯定要等follower同步完消息后才能消费到最新消息,这样的话吞吐量就会下降,所以kafka抛弃了follower的读写功能。
  • 从分区需要从主分区进行数据同步,就是途中绿色线标记部分。
  • 有两个消费组:consumer group0和consumer group1。group0中只有一个消费者,所以这个消费者消费类topic0的两个分区。group2有3个消费者,group2同时消费了topic0和topic1,因为topic0只有两个partition,所以consumer2无分区可以消费。topic1只有一个partition0,所以在消费topic1时,consumer1和consumer2都无partition消费。

总结

  kafka主要消息架构写完了。kafka里面有很多设计思想有很多是值得我们学习的,后面我会再写一些我对kafka原理的理解及kafka常见问题的解决方案。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

hi wei

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值