消息中间件-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.mzph.cn/web/62147.shtml

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

相关文章

如何利用“一键生成ppt”减轻工作压力

随着数字化的快速发展,PPT设计这一传统任务也迎来了新的变化。过去,制作一个简洁、专业的PPT需要花费大量时间与精力。但现在借助科技的力量,一键生成PPT的梦想成真了。从智能生成ppt到ai生成ppt的技术不断进步,令我们能够体验到更…

创造未来:The Sandbox 创作者训练营如何赋能全球创造者

创作者训练营让创造者有能力打造下一代数字体验。通过促进合作和提供尖端工具,The Sandbox 计划确保今天的元宇宙是由一个个创造者共同打造。 2024 年 5 月,The Sandbox 推出了「创作者训练营」系列,旨在重新定义数字创作。「创作者训练营」系…

Docker多架构镜像构建踩坑记

背景 公司为了做信创项目的亮点,需要将现有的一套在X86上运行的应用系统迁移到ARM服务器上运行,整个项目通过后端Java,前端VUEJS开发通过CICD做成Docker镜像在K8S里面运行。但是当前的CICD产品不支持ARM的镜像构建,于是只能手工构…

python学opencv|读取图像(三)放大和缩小图像

【1】引言 前序已经学习了常规的图像读取操作和图像保存技巧,相关文章链接为: python学opencv|读取图像-CSDN博客 python学opencv|读取图像(二)保存彩色图像-CSDN博客 今天我们更近一步,学习放大和缩小图像的技巧&…

D86【python 接口自动化学习】- pytest基础用法

day86 pytest配置testpaths 学习日期:20241202 学习目标:pytest基础用法 -- pytest配置testpaths 学习笔记: pytest配置项 主目录创建pytest.ini文件 [pytest] testpaths./testRule 然后Terminal里直接命令:pytest&#xff…

基于 Apache Dolphinscheduler3.1.9中的Task 处理流程解析

实现一个调度任务,可能很简单。但是如何让工作流下的任务跑得更好、更快、更稳定、更具有扩展性,同时可视化,是值得我们去思考得问题。 Apache DolphinScheduler是一个分布式和可扩展的开源工作流协调平台,具有强大的DAG可视化界…

蓝桥杯2117砍竹子(简单易懂 包看包会版)

问题描述 这天, 小明在砍竹子, 他面前有 n 棵竹子排成一排, 一开始第 i 棵竹子的 高度为 hi​. 他觉得一棵一棵砍太慢了, 决定使用魔法来砍竹子。魔法可以对连续的一 段相同高度的竹子使用, 假设这一段竹子的高度为 H, 那么 用一次魔法可以 把这一段竹子的高度都变为 ⌊H2⌋…

如何进行 JavaScript 性能优化?

要进行 JavaScript 性能优化,我们可以从多个角度进行思考,主要包括减少页面渲染时间、减少内存占用、优化代码执行效率等。以下是优化的一些方法,并结合实际项目代码示例讲解。 目录结构 减少 DOM 操作 缓存 DOM 元素批量更新 DOM 优化 Jav…

CTF-PWN: 全保护下格式化字符串利用 [第一届“吾杯”网络安全技能大赛 如果能重来] 赛后学习(不会)

通过网盘分享的文件:如果能重来.zip 链接: https://pan.baidu.com/s/1XKIJx32nWVcSpKiWFQGpYA?pwd1111 提取码: 1111 --来自百度网盘超级会员v2的分享漏洞分析 格式化字符串漏洞,在printf(format); __int64 sub_13D7() {char format[56]; // [rsp10h] [rbp-40h]…

selenium-常见问题解决方案汇总

selenium-常见问题解决方案 selenium版本selenium代理本地浏览器页面Selenium之多窗口句柄的切换 selenium版本 selenium版本为: 3.141.0 注:selenium4x跟selenium3x会有不同的使用方法, selenium代理本地浏览器页面 利用 Selenium 库实现对 Google C…

Flask使用长连接

Flask使用flask_socketio实现websocket Python中的单例模式 在HTTP通信中,连接复用(Connection Reuse)是一个重要的概念,它允许客户端和服务器在同一个TCP连接上发送和接收多个HTTP请求/响应,而不是为每个新的请求/响…

雨晨 26100.2454 Windows 11 24H2 专业工作站 极简纯净版

文件: 雨晨 26100.2454 Windows 11 24H2 专业工作站极简 install.esd 大小: 1947043502 字节 修改时间: 2024年12月6日, 星期五, 16:38:37 MD5: 339B7FDCA0130D432A0E98957738A9DD SHA1: 2978AE0CEAF02E52EC4135200D4BDBC861E07BE8 CRC32: 8C329C89 简述: 由YCDIS…

[docker中首次配置git环境与时间同步问题]

11月没写东西,12月初赶紧水一篇。 刚开始搭建docker服务器时,网上找一堆指令配置好git后,再次新建容器后忘记怎么配了,,这次记录下。 一、git ssh指令法,该方法不用每次提交时输入密码 前期准备&#xff0…

MongoDB性能监控工具

mongostat mongostat是MongoDB自带的监控工具,其可以提供数据库节点或者整个集群当前的状态视图。该功能的设计非常类似于Linux系统中的vmstat命令,可以呈现出实时的状态变化。不同的是,mongostat所监视的对象是数据库进程。mongostat常用于…

linux下的python打包

linux下的python打包 一、pyinstaller 优点:打包简单,将整个运行环境进行打包 缺点:打包文件大、臃肿、启动慢 安装pyinstaller包 pip install pyinstaller 打包一个文件 pyinstaller -D app.py会在当前路径中生成build、dist文件夹还有…

Python模块之random、hashlib、json、time等内置模块语法学习

Python内置模块语法学习 random、hashlib、json、time、datetime、os等内置模块语法学习 模块 简单理解为就是一个.py后缀的一个文件 分为三种: 内置模块:python自带,可调用第三方模块:别人设计的,可调用自定义模块…

从ctfwiki开始的pwn之旅 5.ret2csu

ret2csu 原理 在 64 位程序中,函数的前 6 个参数是通过寄存器传递的,但是大多数时候,我们很难找到每一个寄存器对应的 gadgets。 这时候,我们可以利用 x64 下的 __libc_csu_init 中的 gadgets。这个函数是用来对 libc 进行初始…

Ceph对象存储

Ceph对象存储1.概念对象存储(Object Storage)是一种用于存储大量非结构化数据的架构模型它使用简单的HTTP或HTTPS协议进行文件访问,而不是传统的文件系统API与传统的文件系统存储方式不同,对象存储不是将数据存储在目录或文件夹中…

嵌入式蓝桥杯学习拓展 LCD翻转显示

通过配置SS和GS两个标志位,实现扫描方向的切换。 将lcd.c的REG_932X_Init函数进行部分修改。 将LCD_WriteReg(R1, 0x0000);修改为LCD_WriteReg(R1,0x0100); 将LCD_WriteReg(R96, 0x2700); 修改为LCD_WriteReg(R96, 0xA700); void REG_932X_Init1(void) {LCD_Wr…

小程序 —— Day1

组件 — view和scroll-view view 类似于HTML中的div,是一个块级元素 案例:通过view组件实现页面的基础布局 scroll-view 可滚动的视图区域,用来实现滚动列表效果 案例:实现纵向滚动效果 scroll-x属性:允许横向滚动…