kafka权威指南(阅读摘录)

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

kafka权威指南(阅读摘录),读书,kafka,分布式

零复制

Kafka 使用零复制技术向客户端发送消息——也就是说,Kafka 直接把消息从文件(或者更确切地说是 Linux 文件系统缓存)里发送到网络通道,而不需要经过任何中间缓冲区。这是 Kafka 与其他大部分数据库系统不一样的地方,其他数据库在将数据发送给客户端之前会先把它们保存在本地缓存里。这项技术避免了字节复制,也不需要管理内存缓冲区,从而获得更好的性能。

如何选定分区数量

为主题选定分区数量并不是一件可有可无的事情,在进行数量选择时,需要考虑如下几个因素。

  • 主题需要达到多大的吞吐量?例如,是希望每秒钟写入 100KB 还是 1GB ?

  • 从单个分区读取数据的最大吞吐量是多少?每个分区一般都会有一个消费者,如果你知道消费者将数据写入数据库的速度不会超过每秒 50MB,那么你也该知道,从一个分区读取数据的吞吐量不需要超过每秒 50MB。

  • 可以通过类似的方法估算生产者向单个分区写入数据的吞吐量,不过生产者的速度一般比消费者快得多,所以最好为生产者多估算一些吞吐量。

  • 每个 broker 包含的分区个数、可用的磁盘空间和网络带宽。

  • 如果消息是按照不同的键来写入分区的,那么为已有的主题新增分区就会很困难。

  • 单个 broker 对分区个数是有限制的,因为分区越多,占用的内存越多,完成首领选举需要的时间也越长。

消费者数量

我们有必要为主题创建大量的分区,在负载增长时可以加入更多的消费者。不过要注意,不要让消费者的数量超过主题分区的数量,多余的消费者只会被闲置。

跟随者副本

首领以外的副本都是跟随者副本。跟随者副本不处理来自客户端的请求,它们唯一的任务就是从首领那里复制消息,保持与首领一致的状态。如果首领发生崩溃,其中的一个跟随者会被提升为新首领。

Kafka 可以在哪些方面作出保证呢?
  • Kafka 可以保证分区消息的顺序。如果使用同一个生产者往同一个分区写入消息,而且消息 B 在消息 A 之后写入,那么 Kafka 可以保证消息 B 的偏移量比消息 A 的偏移量大,而且消费者会先读取消息 A 再读取消息 B。
  • 只有当消息被写入分区的所有同步副本时(但不一定要写入磁盘),它才被认为是“已提交”的。生产者可以选择接收不同类型的确认,比如在消息被完全提交时的确认,或者在消息被写入首领副本时的确认,或者在消息被发送到网络时的确认。
  • 只要还有一个副本是活跃的,那么已经提交的消息就不会丢失。
  • 消费者只能读取已经提交的消息。
复制机制和分区的多副本架构

Kafka 的复制机制和分区的多副本架构是 Kafka 可靠性保证的核心。把消息写入多个副本可以使 Kafka 在发生崩溃时仍能保证消息的持久性。

使用 Kafka 构建数据管道

在使用 Kafka 构建数据管道时,通常有两种使用场景:第一种,把 Kafka 作为数据管道的两个端点之一,例如,把 Kafka 里的数据移动到 S3 上,或者把 MongoDB 里的数据移动到 Kafka 里;第二种,把 Kafka 作为数据管道两个端点的中间媒介,例如,为了把 Twitter 的数据移动到 ElasticSearch 上,需要先把它们移动到 Kafka 里,再将它们从 Kafka 移动到 ElasticSearch 上。

Kafka 为数据管道带来的主要价值

Kafka 为数据管道带来的主要价值在于,它可以作为数据管道各个数据段之间的大型缓冲区,有效地解耦管道数据的生产者和消费者。Kafka 的解耦能力以及在安全和效率方面的可靠性,使它成为构建数据管道的最佳选择。

ETL 和 ELT

数据管道的构建可以分为两大阵营,即 ETL 和 ELT。 ETL 表示提取—转换—加载(Extract-Transform-Load),也就是说,当数据流经数据管道时,数据管道会负责处理它们。这种方式为我们节省了时间和存储空间,因为不需要经过保存数据、修改数据、再保存数据这样的过程。不过,这种好处也要视情况而定。有时候,这种方式会给我们带来实实在在的好处,但也有可能给数据管道造成不适当的计算和存储负担。这种方式“有一个明显不足,就是数据的转换会给数据管道下游的应用造成一些限制,特别是当下游的应用希望对数据进行进一步处理的时候。假设有人在 MongoDB 和 MySQL 之间建立了数据管道,并且过滤掉了一些事件记录,或者移除了一些字段,那么下游应用从 MySQL 中访问到的数据是不完整的。如果它们想要访问被移除的字段,只能重新构建管道,并重新处理历史数据(如果可能的话)。
ELT 表示提取—加载—转换(Extract-Load-Transform)。在这种模式下,数据管道只做少量的转换(主要是数据类型转换),确保到达数据池的数据尽可能地与数据源保持一致。这种情况也被称为高保真(high fidelity)数据管道或数据湖(data lake)架构。目标系统收集“原始数据”,并负责处理它们。这种方式为目标系统的用户提供了最大的灵活性,因为它们可以访问到完整的数据。在这些系统里诊断问题也变得更加容易,“因为数据被集中在同一个系统里进行处理,而不是分散在数据管道和其他应用里。这种方式的不足在于,数据的转换占用了目标系统太多的 CPU 和存储资源。有时候,目标系统造价高昂,如果有可能,人们希望能够将计算任务移出这些系统。

数据管道

数据管道最重要的作用之一是解耦数据源和数据池。

留待实战内容

连接器示例——从MySQL到ElasticSearch

broker最重要的度量指标

如果说 broker 只有一个可监控的度量指标,那么它一定是指非同步分区的数量。该度量指明了作为首领的 broker 有多少个分区处于非同步状态。这个度量可以反映 Kafka 的很多内部问题,从 broker 的崩溃到资源的过度消耗。

集群问题

集群问题一般分为以下两类:

  • 不均衡的负载。
  • 资源过度消耗。
流入和流出速率

流出速率也包括副本流量,也就是说,如果所有主题都设置了复制系数 2,那么在没有消费者客户端的情况下,流出速率与流入速率是一样的。

流式处理

流式处理是指实时地处理一个或多个事件流。流式处理是一种编程范式,就像请求与响应范式和批处理范式那样。

只要持续地从一个无边界的数据集读取数据,然后对它们进行处理并生成结果,那就是在进行流式处理。重点是,整个处理过程必须是持续的。

表与流

在将表与流进行对比时,可以这么想:流包含了变更——流是一系列事件,每个事件就是一个变更。表包含了当前的状态,是多个变更所产生的结果。所以说,表和流是同一个硬币的两面——世界总是在发生变化,用户有时候关注变更事件,有时候则关注世界的当前状态。如果一个系统允许使用这两种方式来查看数据,那么它就比只支持一种方式的系统强大。

时间窗口

如果“移动间隔”与窗口大小相等,这种情况被称为“滚动窗口(tumbling window)”。如果窗口随着每一条记录移动,这种情况被称为“滑动窗口(sliding window)”。

变更数据捕捉(Change Data Capture)

如果能够捕捉数据库的变更事件,并形成事件流,流式处理作业就可以监听事件流,并及时更新缓存。捕捉数据库的变更事件并形成事件流,这个过程被称为 CDC——变更数据捕捉(Change Data Capture)。

基于时间窗口的连接(windowed-join)

如果要连接两个流,那么就是在连接所有的历史事件——将两个流里具有相同键和发生在相同时间窗口内的事件匹配起来。这就是为什么流和流的连接也叫作基于时间窗口的连接(windowed-join)。文章来源地址https://www.toymoban.com/news/detail-628961.html

到了这里,关于kafka权威指南(阅读摘录)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

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

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

相关文章

  • 【分布式技术】消息队列Kafka

    目录 一、Kafka概述 二、消息队列Kafka的好处 三、消息队列Kafka的两种模式 四、Kafka 1、Kafka 定义 2、Kafka 简介 3、Kafka 的特性 五、Kafka的系统架构 六、实操部署Kafka集群  步骤一:在每一个zookeeper节点上完成kafka部署 ​编辑 步骤二:传给其他节点 步骤三:启动3个节点 kafka管理

    2024年01月23日
    浏览(55)
  • 【分布式应用】kafka集群、Filebeat+Kafka+ELK搭建

    主要原因是由于在高并发环境下,同步请求来不及处理,请求往往会发生阻塞。比如大量的请求并发访问数据库,导致行锁表锁,最后请求线程会堆积过多,从而触发 too many connection 错误,引发雪崩效应。 我们使用消息队列,通过异步处理请求,从而缓解系统的压力。消息队

    2024年02月16日
    浏览(53)
  • 分布式应用之Zookeeper和Kafka

    1.定义 2.特点 3.数据结构 4.选举机制 第一次选举 非第一次选举 5.部署 1.概念 中间件是一种独立的系统软件或服务程序,分布式应用软件借助这种软件在不同的技术之间共享资源。 2.消息队列型 3.Web应用型(代理服务器) 1.为什么需要MQ 2.消息队列作用 3.消息队列模式 ①点对

    2024年02月15日
    浏览(46)
  • 分布式 - 消息队列Kafka:Kafka 消费者的消费位移

    01. Kafka 分区位移 对于Kafka中的分区而言,它的每条消息都有唯一的offset,用来表示消息在分区中对应的位置。偏移量从0开始,每个新消息的偏移量比前一个消息的偏移量大1。 每条消息在分区中的位置信息由一个叫位移(Offset)的数据来表征。分区位移总是从 0 开始,假设一

    2024年02月12日
    浏览(50)
  • 分布式消息队列Kafka(四)- 消费者

    1.Kafka消费方式 2.Kafka消费者工作流程 (1)总体工作流程 (2)消费者组工作流程 3.消费者API (1)单个消费者消费 实现代码 (2)单个消费者指定分区消费 代码实现: (3)消费者组消费 复制上面CustomConsumer三个,同时去订阅统一个主题,消费数据,发现一个分区只能被一个

    2023年04月26日
    浏览(49)
  • Kafka:分布式流处理平台的深度解析

    在当今的大数据时代,数据处理和分析的重要性不言而喻。为了满足日益增长的数据处理需求,Apache Kafka 应运而生,成为了分布式流处理领域的佼佼者。本文将详细介绍 Kafka 的基本原理、核心组件、应用场景以及优势,帮助读者全面理解这一强大的数据处理工具。 一、Kaf

    2024年04月28日
    浏览(35)
  • 【新星计划】Kafka分布式发布订阅消息系统

      目录 Kafka分布式发布订阅消息系统 1. 概述 1.1 点对点消息传递模式 1.2 发布-订阅消息传递模式 1.3 Kafka特点 1.4 kafka拓扑图 2. Kafka工作原理 2.1 Kafka核心组件介绍 2.2 Kafka工作流程分析 2.2.1 生产者生产消息过程 2.2.2 消费者消费消息过程 2.2.3 Kafka Topics 2.2.4 Kafka Partition 2.2.4 Kafka

    2024年02月08日
    浏览(46)
  • golang分布式中间件之kafka

    Kafka是一个分布式发布-订阅消息系统,由LinkedIn公司开发。它被设计为快速、可靠且具有高吞吐量的数据流平台,旨在处理大量的实时数据。Kafka的架构是基于发布-订阅模型构建的,可以支持多个生产者和消费者。 在本文中,我们将讨论如何使用Go语言来实现Kafka分布式中间件

    2024年02月07日
    浏览(55)
  • 分享8个分布式Kafka的使用场景

    Kafka 最初是为海量日志处理而构建的。它保留消息直到过期,并让消费者按照自己的节奏提取消息。与它的前辈不同,Kafka 不仅仅是一个消息队列,它还是一个适用于各种情况的开源事件流平台。 下图显示了典型的 ELK(Elastic-Logstash-Kibana)堆栈。Kafka 有效地从每个实例收集日

    2024年02月08日
    浏览(43)
  • 分布式性能测试避坑指南

    当进行分布式性能测试时,以下是一些避坑的指南: 1.定义明确的测试目标 在开始测试之前,确保清楚地定义测试的目标和需求。确定要测试的关键指标和阈值,以便能够准确评估系统的性能。 2.设计合适的测试场景 根据实际使用情况和预期负载,设计具有代表性的测试场

    2024年02月12日
    浏览(47)

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

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

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

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

二维码1

领取红包

二维码2

领红包