Apache Kafka学习

这篇具有很好参考价值的文章主要介绍了Apache Kafka学习。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

一、简介

1.概念:

2.kafka四大API:

3.Kafka消费模式

4.Kafka的基础架构

5.kafka文件存储方式

二、特性

三、优点

1.解耦

2.异步处理

3.流量削峰

4.数据持久化

5.顺序保证

6.可恢复性

四、名词解释

五、QA

Q:如何保证数据高可靠、不丢失?

A:数据丢失的原因

解决方案

producer 生产消息

ack 机制

ack 策略

broker 存储消息

ISR机制 和 AR机制

broker恢复机制

comsumer 消费消息


一、简介

Kafka是由Apache软件基金会开发的一个开源流处理平台,由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者在网站中的所有动作流数据。Kafka是一种消息队列,主要用来处理大量数据状态下的消息队列,一般用来做日志的处理。

官方中文文档 Kafka 中文文档 - ApacheCN

1.概念:

1.Kafka作为一个集群,运行在一台或者多台服务器上

2.Kafka 通过 topic 对存储的流数据进行分类

3.每条记录中包含一个key,一个value和一个timestamp(时间戳)

2.kafka四大API:

Producer API,它允许应用程序向一个或多个 topics 上发送消息记录

Consumer API,允许应用程序订阅一个或多个 topics 并处理为其生成的记录流

Streams API,它允许应用程序作为流处理器,从一个或多个主题中消费输入流并为其生成输出流,有效的将输入流转换为输出流。

Connector API,它允许构建和运行将 Kafka 主题连接到现有应用程序或数据系统的可用生产者和消费者。例如,关系数据库的连接器可能会捕获对表的所有更改

3.Kafka消费模式

一对一的消费,也即点对点的通信,即一个发送一个接收。消息生产者发布消息到Queue队列中,通知消费者从队列中拉取消息进行消费。消息被消费之后则删除,Queue支持多个消费者,但对于一条消息而言,只有一个消费者可以消费,即一条消息只能被一个消费者消费。

Apache Kafka学习

Apache Kafka学习 

 

一对多的消费,即一个消息发送到消息队列,消费者根据消息队列的订阅拉取消息消费。发布/订阅模式,即利用Topic存储消息,消息生产者将消息发布到Topic中,同时有多个消费者订阅此topic,订阅了这个topic的消费者都能消费这条消息,注意发布到Topic中的消息会被多个消费者消费,消费者消费数据之后,数据不会被清除,Kafka会默认保留一段时间,然后再删除。 

Apache Kafka学习

Apache Kafka学习

 

4.Kafka的基础架构

Apache Kafka学习

如上图所示,一个典型的Kafka集群中包含若干Producer(可以是web前端产生的Page View,或者是服务器日志,系统CPU、Memory等),若干broker(Kafka支持水平扩展,一般broker数量越多,集群吞吐率越高),若干Consumer Group,以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置,选举leader,以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker,Consumer使用pull模式从broker订阅并消费消息。

5.kafka文件存储方式

kafka存储的数据是以追加的方式添加到队列尾部。读写数据是顺序读写。

由于生产者生产的消息会不断追加到 log 文件末尾, 为防止 log 文件过大导致数据定位效率低下, Kafka 采取了分片索引机制,将每个 partition 分为多个 segment。

每个 segment对应两个文件——“.index”文件和“.log”文件。 这些文件位于一个文件夹下, 该文件夹的命名规则为: topic 名称+分区序号。例如, first 这个 topic 有三个分区,则其对应的文件夹为 first-0,first-1,first-2。

Apache Kafka学习

 

二、特性

流处理平台有以下三种特性:

  1. 可以让你发布和订阅流式的记录。这一方面与消息队列或者企业消息系统类似。
  2. 可以储存流式的记录,并且有较好的容错性。
  3. 可以在流式记录产生时就进行处理。

kafka特性:

  1. 通过O(1)的磁盘数据结构提供消息的持久化,这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能
  2. 高吞吐量 [2]  :即使是非常普通的硬件Kafka也可以支持每秒数百万 [2]  的消息
  3. 支持通过Kafka服务器和消费机集群来分区消息
  4. 支持Hadoop并行数据加载

三、优点

1.解耦

耦合的状态表示当你实现某个功能的时候,是直接接入当前接口。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层,两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。

正常链路:A调用->B

A发送->MQ订阅->B

2.异步处理

异步处理替代了之前的同步处理,异步处理不需要让流程走完就返回结果,可以将消息发送到消息队列中,然后返回结果,剩下让其他业务处理接口从消息队列中拉取消费处理即可。

3.流量削峰

在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见;如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。高流量的时候,使用消息队列作为中间件可以将流量的高峰保存在消息队列中,从而防止了系统的高请求,减轻服务器的请求处理压力。

4.数据持久化

有些情况下,处理数据的过程会失败。除非数据被持久化,否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中,在把一个消息从队列中删除之前,需要你的处理系统明确的指出该消息已经被处理完毕,从而确保你的数据被安全的保存直到你使用完毕。
 

5.顺序保证

在大多使用场景下,数据处理的顺序都很重要。大部分消息队列本来就是排序的,并且能保证数据会按照特定的顺序来处理。Kafka保证一个Partition内的消息的有序性。

 

6.可恢复性

系统的一部分组件失效时,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。

四、名词解释

Apache Kafka学习 

1.Producer : 消息生产者,就是向 Kafka发送数据 

2.Consumer : 消息消费者,从 Kafka broker中读取数据

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

4.Broker :经纪人,一台 Kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker可以容纳多个 topic

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

6.Partition:分区,为了实现扩展性,一个非常大的Topic可以分布到多个Broker上,一个Topic可以分为多个Partition,每个Partition是一个有序的队列(分区有序,不能保证全局有序)

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

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

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

10.Offset:每个Consumer 消费的信息都会有自己的序号,我们称作当前队列的offset。即消费点位标识消费到的位置。每个消费组都会维护订阅的Topic 下每个队列的offset

五、QA

Q:如何保证数据高可靠、不丢失?

A:数据丢失的原因

Apache Kafka学习

  1. 生产消息阶段  如果出现了网络不可用、消息本身不合格等原因导致消息根本没有被 Broker 接收,那就相当于消息在生产者端就消失了。

  2. 存储消息阶段 Broker 端的消息丢失,一般是由 Broker 服务不可用造成的,例如 Broker 都宕机了导致消息丢失

  3. 消费消息阶段 消费者在消费消息的过程中,会同时更新消费者位移,也就是「已经消费到哪一条消息了」。这里就存在一个问题,当消费一个消息的时候,是先处理消息,成功后再更新位移,还是先更新位移,再处理消息。

    如果先更新位移,在处理消息,当消息处理出现问题,或者更新完位移、消息还未处理,消费者出现宕机等问题的时候,消息就会丢失。

    而如果先处理消息再更新位移,虽然可能会出现重复消费同一个消息的问题,但是,我们可以通过消费者处理逻辑实现幂等的方式来解决。

 

解决方案

producer 生产消息

ack 机制

生产者 acks参数指定了必须要有多少个分区副本收到消息,生产者才认为该消息是写入成功的,这个参数对于消息是否丢失起着重要作用。

ack 策略

现在我们已经知道生产者发送消息有个确认的机制,那么Kafka里是何时确认呢?Kafka是通过配置acks的值确认机制的,这里一共提供了三种策略,对应不同的ACK机制:

  1. acks=0,生产者不等待broker的响应。这种情况下延迟最低,但是有可能丢失数据,比较适合高吞吐量、接受消息丢失的场景。

  2. acks=1,生产者发送消息等待broker的响应,等待leader落盘成功后响应确认。这种情况下,如果是在leader完成同步消息给follower前发生故障,则可能发生消息丢失

  3. acks=-1,生产者发送消息等待broker的响应,直到leader和follower全部落盘成功后才会响应确认。此机制能严格保证不丢失数据。但当所有的follower同步完成之后,leader发送ack响应之前,leader发生了宕机,此时生产者会以为发送失败了,然后会重新发送数据给新的leader,因此该情况下会导致数据重复发送。

broker 存储消息

存储消息阶段需要在消息刷盘之后再给生产者响应,假设消息写入缓存中就返回响应,那么机器突然断电这消息就没了,而生产者以为已经发送成功了。

如果Broker是集群部署,有多副本机制,即消息不仅仅要写入当前,还需要写入副本机中。那配置成至少写入两台机子后再给生产者响应。这样基本上就能保证存储的可靠了。所以broker 消息存储主要是靠的是冗余副本,即多个Replica

ISR机制 和 AR机制

简单来说,分区中的所有副本统称为 AR (Assigned Replicas)。所有与leader副本保持一定程度同步的副本(包括leader副本在内)组成 ISR (In Sync Replicas)。 ISR 集合是 AR 集合的一个子集。消息会先发送到leader副本,然后follower副本才能从leader中拉取消息进行同步。同步期间,follow副本相对于leader副本而言会有一定程度的滞后。前面所说的 ”一定程度同步“ 是指可忍受的滞后范围,这个范围可以通过参数进行配置。于leader副本同步滞后过多的副本(不包括leader副本)将组成 OSR (Out-of-Sync Replied)由此可见,AR = ISR + OSR。正常情况下,所有的follower副本都应该与leader 副本保持 一定程度的同步,即AR=ISR,OSR集合为空。

leader副本负责维护和跟踪 集合中所有follower副本的滞后状态,当follower副本落后太多或失效时,即follower长时间未向leader发送消息,leader副本会把它从 ISR 集合中剔除。如果 集合中所有follower副本“追上”了leader副本,那么leader副本会把它从 OSR 集合转移至 ISR 集合【副本可以在OSP,ISR中来回移动】。默认情况下,当leader副本发生故障时,只有在 ISR 集合中的follower副本才有资格被选举为新的leader,而在 OSR 集合中的副本则没有任何机会(不过这个可以通过配置来改变)。

broker恢复机制

  • LEO:(Log End Offset)每个副本的最后一个offset

  • HW:(High Watermark)高水位,指的是消费者能见到的最大的 offset, ISR 队列中最小的 LEO。可以理解为短板效应

follower 故障:follower 发生故障后会被临时踢出 ISR,待该 follower 恢复后, follower 会读取本地磁盘记录的上次的 HW,并将 log 文件高于 HW 的部分截取掉,从 HW 开始向 leader 进行同步。等该 follower 的 LEO 大于等于该 Partition 的 HW,即 follower 追上 leader 之后,就可以重新加入 ISR 了。

leader 故障:leader 发生故障之后,会从 ISR 中选出一个新的 leader,之后,为保证多个副本之间的数据一致性, 其余的 follower 会先将各自的 log 文件高于 HW 的部分截掉,然后从新的 leader同步数据。

comsumer 消费消息

消费者拿到消息之后直接存入内存队列中就直接返回给消费成功,这样其实是不算消息消费成功的。我们需要考虑消息放在内存之后消费者就宕机了怎么办,若直接设置为消费成功,当前情况下本条消息相当于丢失了。

所以我们应该在消费者真正执行完业务逻辑之后,再发送给消费成功,这才是真正的消费了。文章来源地址https://www.toymoban.com/news/detail-489553.html

到了这里,关于Apache Kafka学习的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 深入学习Kafka之概念解析

    Kafka是一个开源的分布式流处理平台和消息队列系统。 Kafka是一个值得深入学习的开源中间件,其中涉及的概念有很多,今天就来梳理一下,这些概念到底都是什么。 Producers are those client applications that publish (write) events to Kafka 生产者就是那些发布/写事件到Kafka的客户端应用。

    2024年02月22日
    浏览(30)
  • kafka学习-概念与简单实战

    目录 1、核心概念 消息和批次 Topic和Partition Replicas Offset broker和集群 生产者和消费者 2、开发实战 2.1、消息发送 介绍 代码实现 2.2、消息消费 介绍 代码实现 2.3、SpringBoot Kafka pom application.yaml KafkaConfig producer consumer         kafka的基本数据单元,由字节数组组成。可以理解

    2024年02月09日
    浏览(31)
  • kafka学习-基本概念与简单实战

    目录 1、核心概念 消息和批次 Topic和Partition Replicas Offset broker和集群 生产者和消费者 2、开发实战 2.1、消息发送 介绍 代码实现 2.2、消息消费 介绍 代码实现 2.3、SpringBoot Kafka pom application.yaml KafkaConfig producer consumer         kafka的基本数据单元,由字节数组组成。可以理解

    2024年02月09日
    浏览(30)
  • Apache Kafka - 重识Kafka生产者

    Kafka 生产者是 Apache Kafka 中的一个重要组件,它负责将数据发送到 Kafka 集群中。在实时数据处理和流式处理应用程序中,Kafka 生产者扮演着非常重要的角色。 这里我们将介绍 Kafka 生产者的概念、工作原理以及如何使用 Kafka 生产者。 Kafka 生产者是一种用于将数据发送到 Kafk

    2024年02月05日
    浏览(31)
  • 【Spring连载】使用Spring访问 Apache Kafka(十九)----Apache Kafka Streams支持

    从1.1.4版本开始,Spring for Apache Kafka为Kafka Streams提供了非常好的支持。要从Spring应用程序中使用它,kafka-streams jar必须存在于类路径中。它是Spring for Apache Kafka项目的一个可选依赖项,不会自动下载。 参考Apache Kafka Streams文档建议使用该API的方法如下: 因此,我们有两个主要组

    2024年02月20日
    浏览(30)
  • Apache Kafka - 构建数据管道 Kafka Connect

    Kafka Connect 是一个工具,它可以帮助我们将数据从一个地方传输到另一个地方。比如说,你有一个网站,你想要将用户的数据传输到另一个地方进行分析,那么你可以使用 Kafka Connect 来完成这个任务。 Kafka Connect 的使用非常简单。它有两个主要的概念 :source 和 sink 。Source 是

    2024年02月15日
    浏览(35)
  • kafka--kafka的基本概念-副本概念replica

    Broker 表示实际的物理机器节点 Broker1中的绿色P1表示主分片Broker2中的蓝色P1表示副本分片,其余类似,就是主从的概念,如果一个Broker挂掉了,还有其它的节点来保证数据的完整性 P可以看做分区 同一时间点,绿色P1 和紫色P1 不会完全一致,存在一个同步的过程 绿色部分处理

    2024年02月12日
    浏览(30)
  • Apache Flink 和 Apache Kafka 两者之间的集成架构 Flink and Apache Kafka: A Winning Partnership

    作者:禅与计算机程序设计艺术 Apache Flink 和 Apache Kafka 是构建可靠、高吞吐量和低延迟的数据管道(data pipeline)的两个著名的开源项目。2019年4月,两者宣布合作共赢。在这次合作中,Apache Kafka 将提供强大的消息存储能力、Flink 将作为一个分布式数据流处理平台来对其进行

    2024年02月11日
    浏览(40)
  • 【Kafka】Kafka基础概念笔记

    Kafka作为消息队列,有两种模式: 点对点模式 发布/订阅模式 1.1 点对点模式 特点: 消费者主动拉取数据, 消息收到后清除消息 1.2 发布/订阅模式 可以有多个topic主题(浏览、点赞、收藏、评论等) 消费者消费数据之后, 不删除数据 每个消费者相互独立,都可以消费到数据

    2024年02月13日
    浏览(31)
  • Apache Kafka - 灵活控制Kafka消费_动态开启/关闭监听实现

    在实际应用中,往往需要根据业务需求动态开启/关闭Kafka消费者监听。例如,在某些时间段内,可能需要暂停对某个Topic的消费,或者在某些条件下才开启对某个Topic的消费。 在Spring Boot中,要实现动态的控制或关闭消费以及动态开启或关闭监听,可以使用Spring Kafka提供的一些

    2024年02月11日
    浏览(32)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包