从0开始回顾Kafka---系列一

简介: 2、 Kafka有哪些优点和缺点?优点:1. 高吞吐量、低延迟:kafka每秒可以处理几十万条消息,它的延迟最低只有几毫秒。2. 可扩展性:kafka集群支持水平扩展。3. 持久性、可靠性:消息被持久化到本地磁盘,并且支持数据备份防止数据丢失。4. 容错性:允许集群中节点故障(若副本数量为n,则允许n-1个节点故障)。5. 高并发:支持数千个客户端同时读写。缺点:1. 同步收发消息的响应时延比较高,因为当客户端发送一条消息的时候,Kafka 并不会立即发送出去,而是要等一会儿攒一批再发送。2. Kafka 不太适合在线业务场景,由于是批量发送,所以数据达不到真正的实时。3.

概述

1、Kafka是什么?

  1. Kafka 起初是 由 LinkedIn(领英) 公司采用 Scala 语言开发的一个多分区、多副本且基于 ZooKeeper 协调的分布式消息系统,现已被捐献给 Apache 基金会。
  2. 目前 Kafka 已经定位为一个分布式流式处理平台,它以高吞吐、可持久化、可水平扩展、支持流数据处理等多种特性而被广泛使用。
  3. 越来越多的开源分布式处理系统如 Cloudera、Storm、Spark、Flink 等都支持与 Kafka 集成。 、

2、 Kafka有哪些优点和缺点?

优点:

  1. 高吞吐量、低延迟:kafka每秒可以处理几十万条消息,它的延迟最低只有几毫秒。
  2. 可扩展性:kafka集群支持水平扩展。
  3. 持久性、可靠性:消息被持久化到本地磁盘,并且支持数据备份防止数据丢失。
  4. 容错性:允许集群中节点故障(若副本数量为n,则允许n-1个节点故障)。
  5. 高并发:支持数千个客户端同时读写。

缺点:

  1. 同步收发消息的响应时延比较高,因为当客户端发送一条消息的时候,Kafka 并不会立即发送出去,而是要等一会儿攒一批再发送。
  2. Kafka 不太适合在线业务场景由于是批量发送,所以数据达不到真正的实时。
  3. 只支持统一分区内消息有序,无法实现全局消息有序。
  4. 监控不完善,需要安装插件。

3、 Kafka 的用途有哪些?  使用场景如何?  

  1. 消息系统 Kafka 和传统的消息系统(也称作消息中间件)都具备系统解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等功能。与此同时,Kafka 还提供了大多数消息系统难以实现的消息顺序性保障及回溯消费的功能。
  2. 存储系统 Kafka 把消息持久化到磁盘,相比于其他基于内存存储的系统而言,有效地降低了数据丢失的风险。也正是得益于 Kafka 的消息持久化功能和多副本机制,我们可以把 Kafka 作为长期的数据存储系统来使用,只需要把对应的数据保留策略设置为“永久”或启用主题的日志压缩功能即可。
  • 流式处理平台 Kafka 不仅为每个流行的流式处理框架提供了可靠的数据来源,还提供了一个完整的流式处理类库,比如窗口、连接、变换和聚合等各类操作。

4、Zookeeper 对于 Kafka 的作用是什么?

ZooKeeper 是安装 Kafka 集群的必要组件,Kafka 通过 ZooKeeper 来实施对元数据信息的管理,包括集群、broker、主题、分区等内容。

ZooKeeper 是一个开源的分布式协调服务,是 Google Chubby的一个开源实现。分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、配置维护等功能。

5、Kafka的设计架构?

一个典型的 Kafka 体系架构包括若干 Producer、若干 Broker、若干 Consumer,以及一个 ZooKeeper 集群  。

ZooKeeper 是 Kafka 用来负责集群元数据的管理、控制器的选举等操作的。  

Producer 将消息发送到 Broker,Broker 负责将收到的消息存储到磁盘中,而 Consumer 负责从 Broker 订阅并消费消息。  

3个术语:

  1. Producer 生产者,也就是发送消息的一方。生产者负责创建消息,然后将其投递到 Kafka 中。
  2. Consumer 消费者,也就是接收消息的一方。消费者连接到 Kafka 上并接收消息,进而进行相应的业务逻辑处理。
  3. Broker 服务代理节点。对于 Kafka 而言,Broker 可以简单地看作一个独立的 Kafka 服务节点或 Kafka 服务实例。大多数情况下也可以将 Broker 看作一台 Kafka 服务器,前提是这台服务器上只部署了一个 Kafka 实例。

2个重要概念:

  1. 主题(Topic):  Kafka 中的消息以主题为单位进行归类,生产者负责将消息发送到特定的主题(发送到 Kafka 集群中的每一条消息都要指定一个主题),而消费者负责订阅主题并进行消费。
  2. 分区(Partition)主题是一个逻辑上的概念,它还可以细分为多个分区,一个分区只属于单个主题,很多时候也会把分区称为主题分区(Topic-Partition)。
  • 同一主题下的不同分区包含的消息是不同的,分区在存储层面可以看作一个可追加的日志(Log)文件,消息在被追加到分区日志文件的时候都会分配一个特定的偏移量(offset)。

6、Kafka分区的目的?

  1. 提升性能:Kafka 中的分区可以分布在不同的服务器(broker)上,也就是说,一个主题可以横跨多个 broker,以此来提供比单个 broker 更强大的性能。
  2. 实现水平扩展:在创建主题的时候可以通过指定的参数来设置分区的个数,当然也可以在主题创建完成之后去修改分区的数量,通过增加分区的数量可以实现水平扩展。
  3. 提升容灾能力:Kafka 为分区引入了多副本(Replica)机制,通过增加副本数量可以提升容灾能力。
  4. 可以提高并发,因为可以以分区为单位读写。

7、 Kafka 中的 ISR、AR 又代表什么?ISR 的伸缩又指什么?

如下图所示,Kafka 集群中有4个 broker,某个主题中有3个分区,且副本因子(即副本个数)也为3,如此每个分区便有1个 leader 副本和2个 follower 副本。

AR:分区中的所有副本统称为 AR(Assigned Replicas)。

ISR:所有与 leader 副本保持一定程度同步的副本(包括 leader 副本在内)组成ISR(In-Sync Replicas),ISR 集合是 AR 集合中的一个子集。

OSR与 leader 副本同步滞后过多的副本(不包括 leader 副本)组成 OSR(Out-of-Sync Replicas), 由此可见,AR=ISR+OSR。  

ISR 的伸缩

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

8、 Kafka 中的 HW、LEO、LSO等分别代表什么?

HW 是 High Watermark 的缩写,俗称高水位,它标识了一个特定的消息偏移量(offset),消费者只能拉取到这个 offset 之前的消息。

LEO 是 Log End Offset 的缩写,它标识当前日志文件中下一条待写入消息的 offset 。  LEO 的大小相当于当前日志分区中最后一条消息的 offset 值加1。

LSO是 LastStableOffset 的简称,对未完成的事务而言,LSO 的值等于事务中第一条消息的位置(firstUnstableOffset),对已完成的事务而言,它的值同 HW 相同。

LW:Low Watermark 低水位, 代表 AR 集合中最小的 logStartOffset 值

9、 什么是Kafka Lag,怎么计算Kafka Lag ?

Kafka Lag, 消费滞后量 , 很多时候也会被称之为消息堆积量。

如何计算?

在下图中,对每一个分区而言,它的 Lag 等于 HW(高水位)  –  ConsumerOffset( 当前的消费位移 ) 的值。当然这只是针对普通的情况。如果为消息引入了事务,那么 Lag 的计算方式就会有所不同。

如果消费者客户端的 isolation.level 参数配置为“read_uncommitted”(默认),那么 Lag的计算方式不受影响;如果这个参数配置为“read_committed”,那么就要引入 LSO 来进行计 算了。

对未完成的事务而言,LSO 的值等于事务中第一条消息的位置(firstUnstableOffset,如上图所示),对已完成的事务而言,它的值同 HW 相同, 所以我们可以得出一个结论:LSO≤HW≤LEO。(如下图所示)  

所以,对于分区中有未完成的事务,并且消费者客户端的 isolation.level 参数配置为“read_committed”的情况,它对应的 Lag 等于 LSO – ConsumerOffset 的值。  

相关文章
|
弹性计算 负载均衡 监控
jemeter压测【2万用户每秒5次请求在30秒内处理完请求】(二)
jemeter压测【2万用户每秒5次请求在30秒内处理完请求】
439 0
|
4月前
|
人工智能 运维 监控
你的 AI Agent 真的在受控运行吗?
以 OpenClaw 为案例,从行业威胁态势与运行时防护的固有局限出发,系统拆解 AI Agent 可观测体系的设计方法论:通过 Session 审计日志、应用日志与 OpenTelemetry 遥测三条数据管道,构建行为审计、威胁检测、成本管控与运维观测的完整闭环。
你的 AI Agent 真的在受控运行吗?
|
消息中间件 存储 缓存
大厂面试高频:Kafka 工作原理 ( 详细图解 )
本文详细解析了 Kafka 的核心架构和实现原理,消息中间件是亿级互联网架构的基石,大厂面试高频,非常重要,建议收藏。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:Kafka 工作原理 ( 详细图解 )
|
存储 缓存 监控
解决分布式系统演进过程中数据一致性问题的方法
【10月更文挑战第24天】解决分布式系统演进过程中数据一致性问题是一个复杂而又重要的任务。需要综合运用多种方法和技术,根据具体的系统需求和场景,选择合适的解决方案。同时,不断地进行优化和改进,以适应不断变化的分布式系统环境。
773 47
|
消息中间件 存储 负载均衡
【Alibaba中间件技术系列】「RocketMQ技术专题」帮你梳理RocketMQ或Kafka的选择理由以及二者PK
【Alibaba中间件技术系列】「RocketMQ技术专题」帮你梳理RocketMQ或Kafka的选择理由以及二者PK
764 88
【Alibaba中间件技术系列】「RocketMQ技术专题」帮你梳理RocketMQ或Kafka的选择理由以及二者PK
|
消息中间件 存储 缓存
kafka(一)
kafka(一)
|
消息中间件 算法 Java
面试官:Kafka中的key有什么用?
面试官:Kafka中的key有什么用?
807 3
面试官:Kafka中的key有什么用?
|
网络协议 安全 算法
"网络世界的守护者:一探究竟TCP协议如何确保数据传输的绝对安全与可靠"
【8月更文挑战第20天】传输控制协议(TCP)是网络通信中的核心协议之一,它确保数据包能可靠、有序地从源头传输到目的地。TCP采用三次握手的方式建立连接,并通过序列号、确认应答及超时重传来保障数据传输的准确性。此外,TCP还具备流量控制与拥塞控制功能,避免网络拥塞。虽然TCP在可靠性上表现优异,但在快速传输场景中可能存在局限。深入理解TCP对于网络工程师和开发者至关重要。
593 1
|
消息中间件 缓存 Kafka
Kafka的producer如何实现幂等性
Kafka的producer如何实现幂等性
1191 1
|
消息中间件 存储 缓存
【热点】Kafka与传统中间件(MQ,ETL,ESB)的比较
关注公众号“达摩院首座”,了解开发者最真实生活
3158 103
【热点】Kafka与传统中间件(MQ,ETL,ESB)的比较