您的位置:首页 > 运维架构 > 网站架构

Kafka 基础概念及架构

2022-05-15 14:48 453 查看 https://www.cnblogs.com/fanche

一、Kafka 介绍

Kafka是⼀个分布式、分区的、多副本的、多⽣产者、多订阅者,基于zookeeper协调的分布式⽇志系统(也可以当做MQ系统),常⻅可以⽤于web/nginx⽇志、访问⽇志,消息服务等等。 Kafka主要应⽤场景:⽇志收集系统和消息系统

Kafka主要设计目标

  • 以时间复杂度为O(1)的⽅式提供消息持久化能⼒,即使对TB级以上数据也能保证常数时间的访问性能。
  • ⾼吞吐率。即使在⾮常廉价的商⽤机器上也能做到单机⽀持每秒100K条消息的传输。
  • ⽀持Kafka Server间的消息分区,及分布式消费,同时保证每个partition内的消息顺序传输。
  • 同时⽀持离线数据处理和实时数据处理。
  • ⽀持在线⽔平扩展

Kafka消息传递模式:发布-订阅模式(不支持点对点模式)

Kafka消息推拉模式:Kafka只有消息的拉取,没有推送,可以通过轮询实现消息的推送

  1. Kafka在⼀个或多个可以跨越多个数据中⼼的服务器上作为集群运⾏。
  2. Kafka集群中按照主题分类管理,⼀个主题可以有多个分区,⼀个分区可以有多个副本分区。
  3. 每个记录由⼀个键,⼀个值和⼀个时间戳组成。

Kafka 的 4 个核心 API

  1. Producer API
    :允许应⽤程序将记录流发布到⼀个或多个Kafka主题。
  2. Consumer API
    :允许应⽤程序订阅⼀个或多个主题并处理为其⽣成的记录流。
  3. Streams API
    :允许应⽤程序充当流处理器,使⽤⼀个或多个主题的输⼊流,并⽣成⼀个或多个输出主题的输出流,从⽽有效地将输⼊流转换为输出流。
  4. Connector API
    :允许构建和运⾏将Kafka主题连接到现有应⽤程序或数据系统的可重⽤⽣产者或使⽤者。例如,关系数据库的连接器可能会捕获对表的所有更改。

二、Kafka 优势

⾼吞吐量:单机每秒处理⼏⼗上百万的消息量。即使存储了许多TB的消息,它也保持稳定的性能。 ⾼性能:单节点⽀持上千个客户端,并保证零停机和零数据丢失。 持久化数据存储:将消息持久化到磁盘。通过将数据持久化到硬盘以及replication防⽌数据丢失。

  • 零拷贝
  • 顺序读,顺序写
  • 利⽤Linux的⻚缓存

分布式系统:易于向外扩展。所有的Producer、Broker和Consumer都会有多个,均为分布式的。⽆需停机即可扩展机器。多个Producer、Consumer可能是不同的应⽤。 可靠性:Kafka是分布式,分区,复制和容错的。 客户端状态维护:消息被处理的状态是在Consumer端维护,⽽不是由server端维护。当失败时能⾃动平衡。 ⽀持online和offline的场景 ⽀持多种客户端语⾔:Kafka⽀持Java、.NET、PHP、Python等多种语⾔。

三、Kafka 应用场景

⽇志收集:⼀个公司可以⽤Kafka可以收集各种服务的Log,通过Kafka以统⼀接⼝服务的⽅式开放给各种Consumer; 消息系统:解耦⽣产者和消费者、缓存消息等; ⽤户活动跟踪:Kafka经常被⽤来记录Web⽤户或者App⽤户的各种活动,如浏览⽹⻚、搜索、点击等活动,这些活动信息被各个服务器发布到Kafka的Topic中,然后消费者通过订阅这些Topic来做实时的监控分析,亦可保存到数据库; 运营指标:Kafka也经常⽤来记录运营监控数据。包括收集各种分布式应⽤的数据,⽣产各种操作的集中反馈,⽐如报警和报告; 流式处理:⽐如Spark Streaming和Storm。

四、Kafka 基本架构

消息和批次 消息:

  • Kafka 的数据单元称为消息。消息可以看做数据库表的一条“行记录”,消息由字节数组组成。
  • 消息有键,键也是一个字节数组。当消息需要写入不同的分区时,会使用键进行分区。

批次:

  • 消息可以分批写入Kafka,一批次消息属于同一个主题和分区。
  • 分批次写入消息可以减少网络开销。批次越大,单位时间处理消息越多,单个消息传输时间越长;批次消息数据会被压缩,这样能提升传输和存储能力,也需要更多的计算处理。

模式

  • 消息模式(schema)有许多可⽤的选项,以便于理解。如JSON和XML,但是它们缺乏强类型处理能⼒
  • Kafka 使用的 Apache Avro(了解即可)。
  • 数据格式的⼀致性对Kafka很重要,因为它消除了消息读写操作之间的耦合性

主题和分区

  • Kafka的消息通过主题进⾏分类。主题可⽐是数据库的表或者⽂件系统⾥的⽂件夹
  • 主题可以被分为若⼲分区,⼀个主题通过分区分布于Kafka集群中,提供了横向扩展的能⼒

生产者和消费者 生产者:

  • ⽣产者创建消息。⼀个消息被发布到⼀个特定的主题上,⽣产者在默认情况下把消息均衡地分布到主题的所有分区上 直接指定消息的分区
  • 根据消息的key散列取模得出分区
  • 轮询指定分区

消费者:

  • 消费者消费消息。消费者通过偏移量来区分已经读过的消息
  • 消费者是消费组的⼀部分。消费组保证每个分区只能被⼀个消费者使⽤,避免重复消费

broker和集群

  • 一个独立的Kafka服务器称为broker。
  • broker接收来⾃⽣产者的消息,为消息设置偏移量,并提交消息到磁盘保存
  • broker为消费者提供服务,对读取分区的请求做出响应,返回已经提交到磁盘上的消息
  • 单个broker可以轻松处理数千个分区以及每秒百万级的消息量
  • 每个集群都有⼀个broker是集群控制器(⾃动从集群的活跃成员中选举出来,通过Zookeeper的Master选举)控制器负责管理⼯作 将分区分配给broker
  • 监控broker
  • 集群中一个分区属于一个 broker,该broker称为分区首领
  • 一个分区可以分配给多个broker,此时会发生分区复制。分区复制提供了消息冗余和高可用。副本分区不负责处理消息的读写
  • 五、Kafka 核心概念

    5.1 生产者 Producer

    生产者创建消息,将消息发布到主题(Topic)中。一般一个消息会被发布到指定的主题上,然后通过以下几种方式发布到指定主题分区:

    • 默认情况下通过轮询把消息均衡地分布到主题的所有分区上
    • 有时我们可以将消息指定发到某一个分区上。通常是通过消息键和分区器来实现的,分区器可以为消息键计算出一个散列值,通过这个散列值就可以映射到相应的分区上
    • 也可以自定义分区器,我们可以根据不同的业务规则将消息映射到不同分区。

    5.2 消费者 Consumer

    消费者从主题中读取消息

    • 消费者可以订阅一个或多个主题,并按照消息生成的顺序读取
    • 消费者可以通过偏移量(Offset)区分已经读取的消息 偏移量是另⼀种元数据,它是⼀个不断递增的整数值,在创建消息时,Kafka 会把它添加到消息⾥
    • 在给定的分区⾥,每个消息的偏移量都是唯⼀的
    • 消费者把每个分区最后读取的消息偏移量保存在Zookeeper 或Kafka(现在是存在Kafka上的) 上,如果消费者关闭或重启,它的读取状态不会丢失
  • 消费者是消费组的一部分。消费组保证每个分区只能被一个消费者使用
  • 如果某一个消费者失效,就会进行再平衡,重新给消费组中的消费者分配消费分区,以达到高可用的目的
  • 5.3 服务器 Broker

    一个独立的Kafka服务器就是一个 Broker。Broker为消费者提供服务,对读取分区的请求做出响应,返回已经提交到磁盘上的消息。

    • 如果某topic有N个partition,集群有N个broker,那么每个broker存储该topic的⼀个partition
    • 如果某topic有N个partition,集群有(N+M)个broker,那么其中有N个broker存储该topic的⼀个partition,剩下的M个broker不存储该topic的partition数据
    • 如果某topic有N个partition,集群中broker数⽬少于N个,那么⼀个broker存储该topic的⼀个或多个partition。在实际⽣产环境中,尽量避免这种情况的发⽣,这种情况容易导致Kafka集群数据不均衡

    Broker 是集群的组成部分。每个集群都有⼀个broker 同时充当了集群控制器的⻆⾊(⾃动从集群的活跃成员中选举出来):

    • 控制器负责管理⼯作,包括将分区分配给broker 和监控broker

    在集群中,⼀个分区从属于⼀个broker,该broker 被称为分区的⾸领

    5.4 主题 Topic

    每条发布到Kafka的消息都有一个类别,这个类别就是Topic。

    5.5 分区 Partition

    主题可以分为若干个分区,消息可以写主题的某一个分区中。 消息以追加的方式写入分区,然后以先进后出的方式被读取。 Kafka 无法在整个主题范围内保证消息的顺序,但是可以保证消息在单个分区中的顺序。 Kafka 通过分区实现数据冗余和伸缩性。 在需要严格保证消息顺序的情况下,需要将分区设置为 1 。

    5.6 副本 Replicas

    5.6.1 副本概念

    消息被写入主题,每个主题有多个分区,每个分区有多个副本。副本被保存在broker 上,每个broker 可以保存成百上千个属于不同主题和分区的副本 副本有两种类型:

    • ⾸领副本:每个分区都有⼀个⾸领副本。为了保证⼀致性,所有⽣产者请求和消费者请求都会经过这个副本
    • 跟随者副本:⾸领以外的副本都是跟随者副本。跟随者副本不处理来⾃客户端的请求,它们唯⼀的任务就是从⾸领那⾥复制消息,保持与⾸领⼀致的状态。如果⾸领发⽣崩溃,其中的⼀个跟随者会被提升为新⾸领
    5.6.1 副本介绍

    Kafka 通过副本保证高可用。副本分为⾸领副本(Leader)和跟随者副本(Follower)。 跟随者副本包括同步副本和不同步副本,在发⽣⾸领副本切换的时候,只有同步副本可以切换为⾸领副本。

    AR 分区中的所有副本统称为AR(Assigned Repllicas)。AR=ISR+OSR

    ISR

    • 所有与leader副本保持⼀定程度同步的副本(包括Leader)组成 ISR,ISR集合是AR集合中的⼀个⼦集。
    • 消息会先发送到leader副本,然后follower副本才能从leader副本中拉取消息进⾏同步,同步期间内follower副本相对于leader副本⽽⾔会有⼀定程度的滞后。前⾯所说的“⼀定程度”是指可以忍受的滞后范围,这个范围可以通过参数进⾏配置

    OSR

    • 与leader副本同步滞后过多的副本(不包括Leader)组成 OSR。
    • 在正常情况下,所有的follower副本都应该与leader副本保持⼀定程度的同步,即AR=ISR,OSR集合为空

    HW HW是High Watermak的缩写, 俗称⾼⽔位,它表示了⼀个特定消息的偏移量(offset),消费之只能拉取到这个offset之前的消息。

    LEO LEO是Log End Offset的缩写,它表示了当前⽇志⽂件中下⼀条待写⼊消息的offset。

    5.7 偏移量 Offset

    5.7.1 生产者 Offset

    消息写⼊的时候,每⼀个分区都有⼀个offset,这个offset就是⽣产者的offset,同时也是这个分区的最新最⼤的offset 有些时候没有指定某⼀个分区的offset,这个⼯作kafka帮我们完成

    5.7.2 消费者 Offset

    这是某⼀个分区的offset情况,⽣产者写⼊的offset是最新最⼤的值是12,⽽当Consumer A进⾏消费时,从0开始消费,⼀直消费到了9,消费者的offset就记录在9,Consumer B就纪录在了11。等下⼀次他们再来消费时,他们可以选择接着上⼀次的位置消费,当然也可以选择从头消费,或者跳到最近的记录并从“现在”开始消费。

    内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
    标签: