消息中间件-Kafka1-实现原理

消息中间件-Kafka

一、kafka简介

1、概念
Kafka是最初由Linkedin公司开发,是一个分布式、支持分区(partition)、多副本的(replica),基于zookeeper协调的分布式消息系统,它的最大的特性就是可以实时的处理大量数据以满足各种需求场景:比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎,web/nginx日志、访问日志,消息服务等等,用scala语言编写,Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。
2、Kafka特性

  • Kafka具有近乎实时性的消息处理能力,即使面对海量消息也能够高效地存储消息和查询消息。
    Kafka将消息保存在磁盘中,它以顺序读写的方式访问磁盘,从而避免了随机读写磁盘导致的性能瓶颈。
  • Kafka支持批量读写消息,并且会对消息进行批量压缩
  • Kafka支持消息分区,每个分区中的消息保证顺序传输,而分区之间则可以并发操作,具备高并发能力
  • Kafka也支持在线增加分区,支持在线水平扩展
  • Kafka支持为每个分区创建多个副本,其中只会有一个Leader副本负责读写,其他副本只负责与Leader副本进行同步,Kafka会将Leader副本均匀地分布在集群中的服务器上,实现性能最大化,同时具备较强的容灾能力

3、应用场景

  • 在应用系统中可以将Kafka作为传统的消息中间件,实现消息队列和消息的发布/订阅,在某些特定场景下其性能要更优于RabbitMQ、ActiveMQ等传统的消息中间件
  • Kafka也被用作系统中的数据总线,将其接入多个子系统中,子系统会将产生的数据发送到Kafka中保存,之后流转到目的系统中
  • Kafka还可以用作日志收集中心,多个系统产生的日志统一收集到Kafka中,然后由数据分析平台进行统一处理。日志会被Kafka持久化到磁盘,所以同时支持离线数据处理和实时数据处理
  • 事件溯源
    Kafka的持久化存储和顺序消息传递特性使其成为事件溯源的理想选择。通过将系统的事件以消息的形式写入Kafka的主题中,可以实现对系统状态的完全恢复和追溯。这对于需要满足合规性要求或实现事件溯源的系统非常重要,如金融交易系统、电子商务系统等。
  • 流媒体处理
    Kafka在流媒体处理领域也有着广泛的应用。流媒体处理要求系统能够高效地处理大规模的音视频数据流。Kafka的高吞吐量和低延迟特性使其成为一个理想的流媒体处理平台。通过使用Kafka,可以构建高性能的音视频处理系统,实现实时的流媒体传输、转码、存储和分发。

4、数据持久化
在分布式系统中,各个组件是通过网路连接起来的。一般认为网络传输是不可靠的,当数据在两个组件之间进行传递的时候,传输过程可能会失败。除非数据被持久化到磁盘,否则就可能造成消息的丢失。Kafka把数据以消息的形式持久化到磁盘,即使Kafka出现宕机,也可以保证数据不会丢失,通过这一方式规避了数据丢失风险。为了避免磁盘上的数据不断增长,Kafka提供了日志清理、日志压缩等功能,对过时的、已经处理完成的数据进行清除。在磁盘操作中,耗时最长的就是寻道时间,这是导致磁盘的随机I/O性能很差的主要原因。为了提高消息持久化的性能,Kafka采用顺序读写的方式访问,实现了高吞吐量。
5、扩展与容灾
Kafka的每个Topic(主题)都可以分为多个Partition(分区),每个分区都有多个Replica(副本),实现消息冗余备份。每个分区中的消息是不同的,这类似于数据库中水平切分的思想,提高了并发读写的能力。而同一分区的不同副本中保存的是相同的消息,副本之间是一主多从的关系,其中Leader副本负责处理读写请求,Follower副本则只与Leader副本进行消息同步,当Leader副本出现故障时,则从Follower副本中重新选举Leader副本对外提供服务。这样,通过提高分区的数量,就可以实现水平扩展;通过提高副本的数量,就可以提高容灾能力。
Kafka的容灾能力不仅体现在服务端,在Consumer端也有相关设计。Consumer使用pull方式从服务端拉
取消息,并且在Consumer端保存消费的具体位置,当消费者宕机后恢复上线,可以根据自己保存的消费位
置重新拉取需要的消息进行消费,这就不会造成消息丢失。也就是说,Kafka不决定何时、如何消费消息,
而是Consumer自己决定何时、如何消费消息。
Kafka还支持Consumer的水平扩展能力。我们可以让多个Consumer加入一个Consumer Group(消费组),在一个Consumer Group中,每个分区只能分配给一个Consumer消费,当Kafka服务端通过增加分区数量进行水平扩展后,我们可以向Consumer Group中增加新的Consumer来提高整个Consumer Group的消费能力。当Consumer Group中的一个Consumer出现故障下线时,会通过Rebalance操作将下线Consumer负责处理的分区分配给其他Consumer继续处理;当下线Consumer重新上线加入Consumer Group时,会再进行一次Rebalance操作,重新分配分区。当然,一个Consumer Group可以订阅很多不同的Topic,每个Consumer可以同时处理多个分区
6、分区数据的顺序保证
Kafka保证一个分区内的消息的有序性,但是并不保证多个partition之间的数据有顺序。
7、异步通信
Kafka为系统提供了异步处理能力。例如,两个系统需要通过网络进行数据交换,其中一端可以把一个消息放入Kafka中后立即返回继续执行其他路基,不需要等待对端的响应。待后者将处理结果放入Kafka中之后,前者可以从其中获取并解析响应。

二、Kfaka核心概念

  • 消息
    消息是Kafka中最基本的数据单元。消息由一串字节构成,其中主要由key和value构成,key和value也都是byte数组。key的主要作用是根据一定的策略,将此消息路由到指定的分区中,这样就可以保证包含同一key的消息全部写入同一分区中,key可以是null。
  • Topic/分区/Log
    Topic是用于存储消息的逻辑概念,可以看作一个消息集合。每个Topic可以有多个生产者向其中推送(push)消息,也可以有任意多个消费者消费其中的消息。每个Topic可以划分成多个分区(每个Topic都至少有一个分区),同一Topic下的不同分区包含的消息是不同的。每个消息在被添加到分区时,都会被分配一个offset,它是消息在此分区中的唯一编号,Kafka通过offset保证消息在分区内的顺序,offset的顺序性不跨分区,即Kafka只保证在同一个分区内的消息是有序的;同一Topic的多个分区内的消息,Kafka并不保证其顺序性。同一Topic的不同分区会分配在不同的Broker上。分区是Kafka水平扩展性的基础,我们可以通过增加服务器并在其上分配Partition的方式来增加Kafka的并行处理能力。
    分区在逻辑上对应着一个Log,当生产者将消息写入分区时,实际上是写入到了分区对应的Log中。Log是一个逻辑概念,可以对应到磁盘上的一个文件夹。Log由多个Segment组成,每个Segment对应一个日志文件和索引文件。在面对海量数据时,为避免出现超大文件,每个日志文件的大小是有限制的,当超出限制后则会创建新的Segment,继续对外提供服务。这里要注意,因为Kafka采用顺序I/O,所以只向最新的Segment追加数据。
  • 保留策略与日志压缩
    无论消费者是否已经消费了消息,Kafka都会一直保存这些消息,但并不会像数据库那样长期保存。为了避免磁盘被占满,Kafka会配置相应的“保留策略”(retention policy),以实现周期性地删除陈旧的消息。

一种是根据消息保留的时间,当消息在Kafka中保存的时间超过了指定时间,就可以被删除
根据Topic存储的数据大小,当Topic所占的日志文件大小大于一个阈值,则可以开始删除最旧的消息。

Kafka会启动一个后台线程,定期检查是否存在可以删除的消息。“保留策略”的配置是非常灵活的,可以有全局的配置,也可以针对Topic进行配置覆盖全局配置。

  • 消息压缩
    在很多场景中,消息的key与value的值之间的对应关系是不断变化的,就像数据库中的数据会不断被修改一样,消费者只关心key对应的最新value值。此时,可以开启Kafka的日志压缩功能,Kafka会在后台启动一个线程,定期将相同key的消息进行合并,只保留最新的value值。
    压缩过程:
    在这里插入图片描述
  • Broker
    一个单独的Kafka服务器就是一个Broker。Broker的主要工作就是接收生产者发过来的消息,分配offset,之后保存到磁盘中;同时,接收消费者、其他Broker的请求,根据请求类型进行相应处理并返回响应。在一般的生产环境中,一个Broker独占一台物理服务器。
  • 分区副本
    每个分区的副本集合中,都会选举出一个副本作为Leader副本,Kafka在不同的场景下会采用不同的选举策略所有的读写请求都由选举出的Leader副本处理,其他都作为Follower副本,Follower副本仅仅是从Leader 副本处把数据拉取到本地之后,同步更新到自己的Log中。一般情况下,同一分区的多个副本会被分配到不同的Broker上,这样,当Leader所在的Broker宕机之后,可以重新选举新的Leader,继续对外提供服务。
  • ISR(In-Sync Replica)集合
    ISR(In-Sync Replica)集合表示的是目前“可用”(alive)且消息量与Leader相差不多的副本集合,其中每个副本必须满足副本所在节点必须维持着与ZooKeeper的连接副本最后一条消息的offset与Leader副本的最后一条消息的offset之间的差值不能超出指定的阈值*
    每个分区中的Leader副本都会维护此分区的ISR集合。写请求首先由Leader副本处理,之后Follower副本会从Leader上拉取写入的消息,这个过程会有一定的延迟,导致Follower副本中保存的消息略少于Leader副本,只要未超出阈值都是可以容忍的。如果一个Follower副本出现异常,比如:宕机,发生长时间GC而导致Kafka僵死或是网络断开连接导致长时间没有拉取消息进行同步,就会违反上面的两个条件,从而被Leader副本踢出ISR集合。当Follower副本从异常中恢复之后,会继续与Leader副本进行同步,当Follower副本“追上”(即最后一条消息的offset的差值小于指定阈值)Leader副本的时候,此Follower副本会被Leader副本重新加入到ISR中。
  • HW
    HW(HighWatermark)和LEO与上面的ISR集合紧密相关。HW标记了一个特殊的offset,当消费者处理消息的时候,只能拉取到HW之前的消息,HW之后的消息对消费者来说是不可见的。与ISR集合类似,HW也是由Leader副本管理的。当ISR集合中全部的Follower副本都拉取HW指定消息进行同步后,Leader副本会递增HW的值。
  • LEO(Log End Offset)
    LEO是所有的副本都会有的一个offset标记,它指向追加到当前副本的最后一个消息的offset。当生产者向Leader副本追加消息的时候,Leader副本的LEO标记会递增;当Follower副本成功从Leader副本拉取消息并更新到本地的时候,Follower副本的LEO就会增加。

HW与LEO的关系如下图
在这里插入图片描述
①Producer向此Partition推送消息。
②Leader副本将消息追加到Log中,并递增其LEO。
③Follower副本从Leader副本拉取消息进行同步。
④Follower副本将拉取到的消息更新到本地Log中,并递增其LEO。
⑤当ISR集合中所有副本都完成了对offset=11的消息的同步,Leader副本会递增HW。
在①~⑤步完成之后,offset=11的消息就对生产者可见了。

  • 为什么kafka数据冗余要设计成这样?
    常见的数据同步包括同步复制和异步复制。
    同步复制要求所有能工作的Follower副本都复制完,这条消息才会被认为提交成功。一旦有一个
    Follower副本出现故障,就会导致HW无法完成递增,消息就无法提交,生产者获取不到消息。这
    种情况下,故障的Follower副本会拖慢整个系统的性能,甚至导致整个系统不可用。
    异步复制中,Leader副本收到生产者推送的消息后,就认为此消息提交成功。Follower副本则异步
    地从Leader副本同步消息。这种设计虽然避免了同步复制的问题,但同样也存在一定的风险。现在
    假设所有Follower副本的同步速度都比较慢,它们保存的消息量都远远落后于Leader副本。
    在这里插入图片描述
    此时Leader副本所在的Broker突然宕机,则会重新选举新的Leader副本,而新Leader副本中没有原来
    Leader副本的消息,这就出现了消息的丢失,而有些消费者则可能消费了这些丢失的消息,状态变得不可控。
    Kafka权衡了同步复制和异步复制两种策略,通过引入了ISR集合,巧妙地解决了上面两种方案存在的
    缺陷:当Follower副本的延迟过高时,Leader副本被踢出ISR集合,消息依然可以快速提交,生产者可以快速得到响应,避免高延时的Follower副本影响整个Kafka集群的性能。当Leader副本所在的Broker突然宕机的时候,会优先将ISR集合中Follower副本选举为Leader副本,新Leader副本中包含了HW之前的全部消息,这就避免了消息的丢失。值得注意是,Follower副本可以批量地从Leader副本复制消息,这就加快了网络I/O,Follower 副本在更新消息时是批量写磁盘,加速了磁盘的I/O,极大减少了Follower与Leader的差距。
  • Cluster(集群)与Controller(指挥中心)
    多个Broker可以做成一个Cluster(集群)对外提供服务,每个Cluster当中会选举出一个Broker来担任
    Controller,Controller是Kafka集群的指挥中心,而其他Broker则听从Controller指挥实现相应的功能。
    Controller负责管理分区的状状态、管理每个分区的副本状态、监听Zookeeper中数据的变化等工作。
    Controller也是一主多从的实现,所有Broker都会监听Controller Leader的状态,当Leader Controller出现故障时则重新选举新的Controller Leader。
  • 生产者
    生产者(Producer)的主要工作是生产消息,并将消息按照一定的规则推送到Topic的分区中。这里选
    择分区的“规则”可以有很多种,例如:根据消息的key的Hash值选择分区,或按序轮询全部分区的方式。
  • 消费者
    消费者(Consumer)的主要工作是从Topic中拉取消息,并对消息进行消费。某个消费者消费到
    Partition的哪个位置(offset)的相关信息,是Consumer自己维护的。 如下图
    在这里插入图片描述
  • Consumer Group 消费者组
    在Kafka中,多个Consumer可以组成一个Consumer Group,一个Consumer只能属于一个Consumer
    Group。Consumer Group保证其订阅的Topic的每个分区只被分配给此Consumer Group中的一个消费者处理。如果不同Consumer Group订阅了同一Topic,Consumer Group彼此之间不会干扰。这样,如果要实现一个消息可以被多个消费者同时消费(“广播”)的效果,则将每个消费者放入单独的一个Consumer Group;如果要实现一个消息只被一个消费者消费(“独占”)的效果,则将所有Consumer放入一个Consumer Group中。
    消费者组消费消息如图:
    在这里插入图片描述
    Consumer Group除了实现“独占”和“广播”模式的消息处理,Kafka还通过Consumer Group实现了消费者的水平扩展和故障转移。在上图中,当Consumer3的处理能力不足以处理两个Partition中的数据时,可以通过向Consumer Group中添加消费者的方式,触发Rebalance操作重新分配分区与消费者的对应关系,从而实现水平扩展。如下图所示,添加Consumer4之后,Consumer3只消费Partition2中的消息,Partition3中的消息则由Consumer4来消费。
    在这里插入图片描述
    下面来看消费者出现故障的场景,当Consumer4宕机时,Consumer Group会自动重新分配分区,如下图所示,由Consumer3接管Consumer4对应的分区继续处理。
    在这里插入图片描述
    注,Consumer Group中消费者的数量并不是越多越好,当其中消费者数量超过分区的数量时,会导
    致有消费者分配不到分区,从而造成消费者的浪费

三、Kafak消息处理流程图

  • 单个Kafka Server单体模式
    在这里插入图片描述
    Kafka的每个Topic(主题)都可以分为多个Partition(分区),每个分区都有多个Replica(副本),实现消息冗余备份。每个分区中的消息是不同的,这类似于数据库中水平切分的思想,提高了并发读写的能力。而同一分区的不同副本中保存的是相同的消息,副本之间是一主多从的关系,其中Leader副本负责处理读写请求,Follower副本则只与Leader副本进行消息同步,当Leader副本出现故障时,则从Follower副本中重新选举Leader副本对外提供服务。
  • 集群Kafak Server 集群模式
    在这里插入图片描述
    如上所示,生产者会根据业务逻辑产生消息,之后根据路由规则将消息发送到指定分区的Leader副本所在的Broker上。在Kafka服务端接收到消息后,会将消息追加到Log中保存,之后Follower副本会与
    Leader副本进行同步,当ISR集合中所有副本都完成了此消息的同步后,则Leader副本的HW会增加,并向生产者返回响应。
    当消费者加入到Consumer Group时,会触发Rebalance操作将分区分配给不同的消费者消费。随后,消费者会恢复其消费位置,并向Kafka服务端发送拉取消息的请求,Leader副本会验证请求的offset以及其他相关信息,最后返回消息。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/483382.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

【Spring】Spring IOCDI:架构旋律中的“依赖交响”与“控制华章”

前言 🌟🌟本期讲解关于Spring IOC&DI的详细介绍~~~ 🌈感兴趣的小伙伴看一看小编主页:GGBondlctrl-CSDN博客 🔥 你的点赞就是小编不断更新的最大动力 🎆那么…

44 基于32单片机的博物馆安全监控系统设计

目录 一、主要功能 二、硬件资源 三、程序编程 四、实现现象 一、主要功能 检测 分别是温湿度 光照 PM2.5、烟雾、红外,然后用OLED屏幕显示, 红外超过阈值则蜂鸣器报警,这是防盗报警;温度或烟雾超过阈值,则蜂鸣器…

VScode离线下载扩展安装

在使用VScode下在扩展插件时,返现VScode搜索不到插件,网上搜了好多方法,都不是常规操作,解决起来十分麻烦,可以利用离线下载安装的方式安装插件!亲测有效!!! 1.找到VScod…

文生视频、图生视频 AI 大模型开源项目介绍【持续更新】

Open-Sora 介绍:Open-Sora是一个由北京大学和兔展科研团队推出的开源项目,旨在推动视频生成技术的发展。Open-Sora致力于高效制作高质量视频,通过开源原则,使高级视频生成技术变得民主化,并提供一个简化且用户友好的平…

Burp Suite 实战指南:Proxy 捕获与修改流量、HTTP History 筛选与分析

声明! 学习视频来自B站up主 **泷羽sec** 有兴趣的师傅可以关注一下,如涉及侵权马上删除文章,笔记只是方便各位师傅的学习和探讨,文章所提到的网站以及内容,只做学习交流,其他均与本人以及泷羽sec团队无关&a…

基于Vue实现的移动端手机商城项目 电商购物网站 成品源码

📂文章目录 一、📔网站题目 二、✍️网站描述 三、📚网站介绍 四、🌐网站演示 📸部分截图 🎬视频演示 五、⚙️网站代码 🧱项目结构 💒vue代码预览 六、🔧完整…

.NET 9 中 LINQ 新增功能实现过程

本文介绍了.NET 9中LINQ新增功能,包括CountBy、AggregateBy和Index方法,并提供了相关代码示例和输出结果,感兴趣的朋友跟随我一起看看吧 LINQ 介绍 语言集成查询 (LINQ) 是一系列直接将查询功能集成到 C# 语言的技术统称。 数据查询历来都表示为简单的…

yarn install遇到问题处理

1、Yarn在尝试安装一个依赖项时遇到了问题。具体来说,这个错误指出期望提升(hoist)的包的manifest文件丢失了,这通常是因为缓存中的数据损坏或不一致所致。 解决方法:有以下两种 1、清除Yarn缓存:运行 yarn…

遇到问题:hive中的数据库和sparksql 操作的数据库不是同一个。

遇到的问题: 1、hive中的数据库和sparksql 操作的数据库不同步。 观察上面的数据库看是否同步 !!! 2、查询服务器中MySQL中hive的数据库,发现创建的位置没有在hdfs上,而是在本地。 这个错误产生的原因是&…

大数据-240 离线数仓 - 广告业务 测试 ADS层数据加载 DataX数据导出到 MySQL

点一下关注吧!!!非常感谢!!持续更新!!! Java篇开始了! 目前开始更新 MyBatis,一起深入浅出! 目前已经更新到了: Hadoop&#xff0…

计算机网络-网络安全

网络安全介绍 端口扫描 安全包括那些方面: 数据存储安全、应用程序安全、操作系统安全、网络安全、物理安全、用户安全教育 一、网络安全问题概述 1. 计算机网络面临的安全性威胁 计算机网络上的通信面临以下的四种威胁: 截获——从网络上窃听他人…

linux 获取公网流量 tcpdump + python + C++

前言 需求为,统计linux上得上下行公网流量,常规得命令如iftop 、sar、ifstat、nload等只能获取流量得大小,不能区分公私网,所以需要通过抓取网络包并排除私网段才能拿到公网流量。下面提供了一些有效得解决思路,提供了…

【CSS in Depth 2 精译_066】11.2 颜色的定义(上)

当前内容所在位置(可进入专栏查看其他译好的章节内容) 第四部分 视觉增强技术 ✔️【第 11 章 颜色与对比】 ✔️ 11.1 通过对比进行交流 11.1.1 模式的建立11.1.2 还原设计稿 11.2 颜色的定义 ✔️ 11.2.1 色域与色彩空间11.2.2 深入理解颜色表示法 文…

论文导读 I RAFT:使语言模型适应特定领域的RAG

摘要 随着大语言模型(LLMs)的发展,这些模型在广泛的任务中展现出了卓越的性能。然而,当这些模型应用于特定领域时,如何有效融入新信息仍然是一个未解决的问题。本文提出了检索增强微调(RAFT)&a…

华为HarmonyOS 让应用快速拥有账号能力 -- 2 获取用户头像昵称

场景介绍 如应用需要完善用户头像昵称信息,可使用Account Kit提供的头像昵称授权能力,用户允许应用获取头像昵称后,可快速完成个人信息填写。以下只针对Account kit提供的头像昵称授权能力进行介绍,若要获取头像还可通过场景化控…

高校数字化运营平台解决方案:构建统一的服务大厅、业务平台、办公平台,助力打造智慧校园

教育数字化是建设教育强国的重要基础,利用技术和数据助推高校管理转型,从而更好地支撑教学业务开展。 近年来,国家多次发布政策,驱动教育行业的数字化转型。《“十四五”国家信息化规划》,推进信息技术、智能技术与教育…

华为HarmonyOS 让应用快速拥有账号能力 -- 1 华为账号一键登录

概述 华为账号一键登录是基于OAuth 2.0协议标准和OpenID Connect协议标准构建的OAuth2.0 授权登录系统,应用可以通过华为账号一键登录能力方便地获取华为账号用户的身份标识和手机号,快速建立应用内的用户体系。 优势: 利用系统账号的安全…

C语言:指针与数组

一、. 数组名的理解 int arr[5] { 0,1,2,3,4 }; int* p &arr[0]; 在之前我们知道要取一个数组的首元素地址就可以使用&arr[0],但其实数组名本身就是地址,而且是数组首元素的地址。在下图中我们就通过测试看出,结果确实如此。 可是…

是什么阻断了kafka与zk的链接?

转载说明:如果您喜欢这篇文章并打算转载它,请私信作者取得授权。感谢您喜爱本文,请文明转载,谢谢。 问题描述: 前几天部署一套环境,先把zk集群起来了,之后第二天在启动kafka的时候,…

MAUI APP开发蓝牙协议的经验分享:与跳绳设备对接

在开发MAUI应用程序时,蓝牙协议的应用是一个重要的环节,尤其是在需要与外部设备如智能跳绳进行数据交换的场景中。以下是我在开发过程中的一些经验和心得,希望能为你的项目提供帮助。 1. 蓝牙协议基础 蓝牙协议是无线通信的一种标准&#x…