Kafka的详细介绍

消息队列的介绍

  • 消息(Message):是指在应用之间传送的数据,消息可以非常简单,比如只包含文本字符串,也可以更复杂,可能包含嵌入对象。–点与点之间,点与多点之间传递的数据,传递的信息。
  • 消息队列(Message Queue):是一种应用间的通信方式,消息发送后可以立即返回,由消息系统来确保信息的可靠专递,消息发布者只管把消息发布到MQ中而不管谁来取,消息使用者只管从MQ中取消息而不管谁发布的,这样发布者和使用者都不用知道对方的存在,是一种应用间的通信方式以队列的形式传递。

消息队列的应用场景

消息队列在实际应用中包括如下四个场景:

  • 应用耦合:多应用间通过消息队列对同一消息进行处理,避免调用接口失败导致整个过程失败;

  • 异步处理:多应用对消息队列中同一消息进行处理,应用间并发处理消息,相比串行处理,减少处理时间;

  • 限流削峰:广泛应用于秒杀或抢购活动中,避免流量过大导致应用系统挂掉的情况;

  • 消息驱动的系统:系统分为消息队列、消息生产者、消息消费者,生产者负责产生消息,消费者(可能有多个)负责对消息进行处理;

消息队列的两种模式

消息队列包括两种模式:

  • 点对点模式(point to point, queue)
    点对点模式下包括三个角色:
    消息队列
    发送者 (生产者)
    接收者(消费者)

    在这里插入图片描述
    消息发送者生产消息发送到queue中,然后消息接收者从queue中取出并且消费消息。消息被消费以后,queue中不再有存储,所以消息接收者不可能消费到已经被消费的消息。
    点对点模式特点:
  1. 每个消息只有一个接收者(Consumer)(即一旦被消费,消息就不再在消息队列中);
  2. 发送者和接收者间没有依赖性,发送者发送消息之后,不管有没有接收者在运行,都不会影响到发送者下次发送消息;
  3. 接收者在成功接收消息之后需向队列应答成功,以便消息队列删除当前接收的消息;
  • 发布/订阅模式(publish/subscribe,topic)
    发布/订阅模式下包括三个角色:
    角色主题(Topic)
    发布者(Publisher)
    订阅者(Subscriber)

    在这里插入图片描述
    发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。
    发布/订阅模式特点:
  1. 每个消息可以有多个订阅者;
  2. 发布者和订阅者之间有时间上的依赖性。针对某个主题(Topic)的订阅者,它必须创建一个订阅者之后,才能消费发布者的消息。
  3. 为了消费消息,订阅者需要提前订阅该角色主题,并保持在线运行;

kafka的基本介绍

官网:http://kafka.apache.org/
kafka是一个分布式,分区的,多副本的,多订阅者的消息发布订阅系统(分布式MQ系统),可以用于搜索日志,监控日志,访问日志等。
最初由linkedin公司开发,使用scala语言编写,
Kafka is a distributed,partitioned,replicated commit logservice。
kafka对消息保存时根据Topic进行归类,发送消息者成为Producer,消息接受者成为Consumer,此外kafka集群有多个kafka实例组成,每个实例(server)成为broker。无论是kafka集群,还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息

kafka的好处

可靠性: 分布式的,分区,复制和容错。
可扩展性: kafka消息传递系统轻松缩放,无需停机。
耐用性: kafka使用分布式提交日志,这意味着消息会尽可能快速的保存在磁盘上,因此它是持久的。
性能: kafka对于发布和定于消息都具有高吞吐量。即使存储了许多TB的消息,他也爆出稳定的性能。
kafka非常快: 保证零停机和零数据丢失。

分布式的发布与订阅系统

apache kafka是一个分布式发布-订阅消息系统和一个强大的队列,可以处理大量的数据,并使能够将消息从一个端点传递到另一个端点,kafka适合离线和在线消息消费。
kafka消息保留在磁盘上,并在集群内复制以防止数据丢失。
kafka构建在zookeeper同步服务之上。它与apache和spark非常好的集成,应用于实时流式数据分析。

kafka的主要应用场景

指标分析
kafka通常用于操作监控数据。用于接收、聚合来自多种应用程序的统计信息, 以便于向产生环境中的数据集中反馈数据


日志聚合解决方法
kafka可用于跨组织从多个服务器收集日志,并使他们以标准的合适提供给多个服务器。


流式处理
流式处理框架(spark,storm,flink)从主题中读取数据,对齐进行处理,并将处理后的数据写入新的主题,供用户和应用程序使用,kafka的强耐久性在流处理的上下文中也非常的有用。

kafka的架构介绍

在这里插入图片描述

  1. 生产者API
    允许应用程序发布记录流至一个或者多个kafka的主题(topics)。
  2. 消费者API
    允许应用程序订阅一个或者多个主题,并处理这些主题接收到的记录流。
  3. StreamsAPI
    允许应用程序充当流处理器(stream processor),从一个或者多个主题获取输入流,并生产一个输出流到一个或 者多个主题,能够有效的变化输入流为输出流。
  4. ConnectAPI
    允许构建和运行可重用的生产者或者消费者,能够把kafka主题连接到现有的应用程序或数据系统。例如:一个连接到关系数据库的连接器可能会获取每个表的变化。

kafka架构内部细节剖析

在这里插入图片描述

在这里插入图片描述
说明:kafka支持消息持久化,消费端为拉模型来拉取数据,消费状态和订阅关系有客户端负责维护,消息消费完后,不会立即删除,会保留历史消息。因此支持多订阅时,消息只会存储一份就可以了。

  • Broker:kafka集群中包含一个或者多个服务实例,这种服务实例被称为Broker
  • Topic:每条发布到kafka集群的消息都有一个类别,这个类别就叫做Topic
  • Partition:Partition是一个物理上的概念,每个Topic包含一个或者多个Partition
  • segment:一个partition当中存在多个segment文件段,每个segment分为两部分,.log文件和.index文件,其中.index文件是索引文件,主要用于快速查询.log文件当中数据的偏移量位置
  • Producer:负责发布消息到kafka的Broker中。
  • Consumer:消息消费者,向kafka的broker中读取消息的客户端
  • Consumer Group:每一个Consumer属于一个特定的Consumer Group(可以为每个Consumer指定 groupName)
    .log:存放数据文件
    .index:存放.log文件的索引数据
    在这里插入图片描述

kafka主要组件说明

  1. kafka当中的producer说明:
    producer主要是用于生产消息,是kafka当中的消息生产者,生产的消息通过topic进行归类,保存到kafka的broker里面去
  2. kafka当中的topic说明:
  • kafka将消息以topic为单位进行归类
  • topic特指kafka处理的消息源(feeds of messages)的不同分类。
  • topic是一种分类或者发布的一些列记录的名义上的名字。kafka主题始终是支持多用户订阅的;也就是说,一个主题可以有零个,一个或者多个消费者订阅写入的数据。
  • 在kafka集群中,可以有无数的主题。
  • 生产者和消费者消费数据一般以主题为单位。更细粒度可以到分区级别。
  1. kafka当中的partition说明:
    kafka当中,topic是消息的归类,一个topic可以有多个分区,每个分区保存部分topic的数据,所有的partition当中的数据全部合并起来,就是一个topic当中的所有的数据,
    一个broker服务下,是否可以创建多个分区?
    可以的,broker数与分区数没有关系; 在kafka中,每一个分区会有一个编号:编号从0开始
    每一个分区的数据是有序的
    说明-数据是有序 如何保证一个主题下的数据是有序的?(生产是什么样的顺序,那么消费的时候也是什么样的顺序)
    在这里插入图片描述
    topic的Partition数量在创建topic时配置。
    Partition数量决定了每个Consumer group中并发消费者的最大数量。
    例如:Consumer group A 有两个消费者来读取4个partition中数据;Consumer group B有四个消费者来读取4个 partition中的数据
    在这里插入图片描述
  2. kafka当中partition的副本数说明
    kafka分区副本数(kafka Partition Replicas)
    在这里插入图片描述
    副本数(replication-factor):控制消息保存在几个broker(服务器)上,一般情况下小于等于broker的个数

例如:一个broker服务下,是否可以创建多个副本因子?
不可以;创建主题时,副本因子应该小于等于可用的broker数。 副本因子过程图
在这里插入图片描述
副本因子操作以分区为单位的。每个分区都有各自的主副本和从副本;
主副本叫做leader,从副本叫做 follower(在有多个副本的情况下,kafka会为同一个分区下的所有分区,设定角色关系:一个leader和N个 follower),处于同步状态的副本叫做in-sync-replicas(ISR);
follower通过拉的方式从leader同步数据。
消费者和生产者都是从leader读写数据,不与follower交互。
副本因子的作用:让kafka读取数据和写入数据时的可靠性。
副本因子是包含本身,同一个副本因子不能放在同一个Broker中。
如果某一个分区有三个副本因子,就算其中一个挂掉,那么只会剩下的两个中,选择一个leader,但不会在其他的broker中,另启动一个副本(因为在另一台启动的话,存在数据传递,只要在机器之间有数据传递,就会长时间占用网络IO,kafka是一个高吞吐量的消息系统,这个情况不允许发生)所以不会在零个broker中启动。
如果所有的副本都挂了,生产者如果生产数据到指定分区的话,将写入不成功。
lsr表示:当前可用的副本

  1. kafka当中的segment说明:

一个partition当中有多个segment文件组成,每个segment文件,包含两部分,一个是.log文件,另外一个是.index文件,其中.log文件包含了我们发送的数据存储,.index文件,记录的是我们.log文件的数据索引值,以便于我们加快数据的查询速度

索引文件与数据文件的关系:
既然它们是一一对应成对出现,必然有关系。索引文件中元数据指向对应数据文件中message的物理偏移地址
比如:索引文件中3,497代表:数据文件中的第三个message,它的偏移地址为497。再来看数据文件中,Message 368772表示:在全局partiton中是第368772个message。
注:segment index file采取稀疏索引存储方式,它减少索引文件大小,通过mmap可以直接内存操作,稀疏索引为数据文件的每个对应message设置一个元数据指针,它比稠密索引节省了更多的存储空间,但查找起来需要消耗更多的时间。
在这里插入图片描述

  1. kafka当中的partition的offset:
    任何发布到此partition的消息都会被直接追加到log文件的尾部,每条消息在文件中的位置称为offset(偏移量),
    offset是一个long类型数字,它唯一标识了一条消息,消费者通过(offset,partition,topic)跟踪记录。
    在这里插入图片描述

  2. kafka分区与消费组的关系:
    消费组: 由一个或者多个消费者组成,同一个组中的消费者对于同一条消息只消费一次。
    某一个主题下的分区数,对于消费组来说,消费者应该小于等于该主题下的分区数。如下所示:
    如:某一个主题有4个分区,那么消费组中的消费者应该小于4,而且最好与分区数成整数倍1 2 4同一个分区下的数据,在同一时刻,不能同一个消费组的不同消费者消费
    总结:分区数越多,同一时间可以有越多的消费者来进行消费,消费数据的速度就会越快,提高消费的性能

  3. kafka当中的consumer:
    consumer是kafka当中的消费者,主要用于消费kafka当中的数据,任何一个消费者都必定需要属于某一个消费组当中。
    任意时刻,一个分区当中的数据,只能被kafka当中同一个消费组下面的一个线程消费

发布了80 篇原创文章 · 获赞 153 · 访问量 6万+

猜你喜欢

转载自blog.csdn.net/weixin_45737446/article/details/104944004
今日推荐