首页 > 其他分享 >Kafka 为什么那么快?

Kafka 为什么那么快?

时间:2022-12-08 10:08:04浏览次数:37  
标签:为什么 那么 消费者 分区 写入 Broker Kafka 消息

有人说:他曾在一台配置较好的机子上对 ​​Kafka​​ 进行性能压测,压测结果是 ​​Kafka​​ 单个节点的极限处理能力接近每秒 ​​2000万​​ 条消息,吞吐量达到每秒 ​​600MB​​。

那 ​​Kafka​​ 为什么这么快?如何做到这个高的性能?

本篇文章主要从这 3 个角度来分析:

  • 生产端
  • 服务端 ​​Broker​
  • 消费端

先来看下生产端发送消息,​​Kafka​​ 做了哪些优化?

(1)生产端 ​​Producer​

Kafka 为什么那么快?_服务端

先来回顾下 ​​Producer​​ 生产者发送消息的流程:

  1. 首先指定消息发送到哪个 Topic
  2. 选择一个 Topic 的分区 partitiion,默认是轮询来负载均衡。

也可以指定一个分区 ​​key​​,根据 ​​key​​ 的 ​​hash​​ 值来分发到指定的分区。

也可以自定义 ​​partition​​ 来实现分区策略。

  1. 找到这个分区的 leader partition
  2. 与所在机器的 Broker 的 socket 建立通信。
  3. 发送 Kafka 自定义协议格式的请求(包含携带的消息、批量消息)。

将思绪集中在消息发送时候,可发现这两个华点:批量消息自定义协议格式

  1. 批量发送:减少了与服务端 ​​Broker​​ 处理请求的次数,从而提升总体的处理能力。

调用 ​​send()​​ 方法时,不会立刻把消息发送出去,而是缓存起来,选择恰当时机把缓存里的消息划分成一批数据,按批次发送给服务端 ​​Broker​​。

  1. 自定义协议格式:序列化方式和压缩格式都能减少数据体积,从而节省网络资源消耗。

各种压缩算法对比:

  • 吞吐量方面:​​LZ4​​ > ​​Snappy​​ > ​​zstd​​ 和 ​​GZIP​
  • 压缩比方面:​​zstd​​ > ​​LZ4​​ > ​​GZIP​​ > ​​Snappy​
  • Kafka 为什么那么快?_服务端_02


(2)服务端 ​​Broker​

​Broker​​ 的高性能主要从这 3 个方面体现:

  1. ​PageCache​​ 缓存
  2. ​Kafka​​ 的文件布局 以及 磁盘文件顺序写入
  3. 零拷贝 ​​sendfile​​:加速消费流程

下面展开讲讲。

1)​​PageCache​​ 加速消息读写

使用 ​​PageCache​​ 主要能带来如下好处:

  1. 写入文件的时候:操作系统会先把数据写入到内存中的 ​​PageCache​​,然后再一批一批地写到磁盘上,从而减少磁盘 ​​IO​​ 开销。
  2. 读取文件的时候:也是从 PageCache 中来读取数据。

如果消息刚刚写入到服务端就会被消费,按照 ​​LRU​​ 的“优先清除最近最少使用的页”这种策略,读取的时候,对于这种刚刚写入的 ​​PageCache​​,命中的几率会非常高。

2)​​Kafka​​ 的文件布局 以及 磁盘文件顺序写入

文件布局如下图所示:


Kafka 为什么那么快?_数据_03

主要特征是:文件的组织方式是“​​topic​​ + 分区”,每一个 ​​topic​​ 可以创建多个分区,每一个分区包含单独的文件夹。

​Kafka​​​ 在分区级别实现文件顺序写:即多个文件同时写入,更能发挥磁盘 ​​IO​​ 的性能。

  • 相对比 ​​RocketMQ​​: RocketMQ 在消息写入时追求极致的顺序写,所有的消息不分主题一律顺序写入 commitlog 文件, topic 和 分区数量的增加不会影响写入顺序。
  • 弊端: Kafka 在消息写入时的 IO 性能,会随着 topic 、分区数量的增长先上升,后下降。

所以使用 ​​Kafka​​ 时,要警惕 ​​Topic​​ 和 分区数量。

3)零拷贝 ​​sendfile​​:加速消费流程

当不使用零拷贝技术读取数据时:

Kafka 为什么那么快?_零拷贝_04

流程如下:

  1. 消费端 Consumer:向 Kafka Broker 请求拉取消息
  2. ​Kafka Broker​​ 从 OS Cache 读取消息到 应用程序的内存空间:
  1. 若 ​​OS Cache​​ 中有消息,则直接读取
  2. 若 ​​OS Cache​​ 中无消息,则从磁盘里读取
  1. 再通过网卡,socket 将数据发送给 消费端Consumer

当使用零拷贝技术读取数据:

Kafka 为什么那么快?_零拷贝_05

​Kafka​​​ 使用零拷贝技术可以把这个复制次数减少一次,直接从 ​​PageCache​​ 中把数据复制到 ​​Socket​​ 缓冲区中。

  • 这样不用将数据复制到用户内存空间。
  • ​DMA​​ 控制器直接完成数据复制,不需要 ​​CPU​​ 参与,速度更快。

(3)消费端 ​​Consumer​

消费者只从 ​​Leader​​分区批量拉取消息。

为了提高消费速度,多个消费者并行消费比不可少。 ​​Kafka​​ 允许创建消费组(唯一标识 ​​group.id​​),在同一个消费组的消费者共同消费数据。

举个栗子:

  • 有两个 ​​Kafka Broker​​,即有 2个机子
  • 有一个主题:​​TOPICA​​,有 3 个分区(0, 1, 2)

如上图,举例 4 中情况:

  1. ​group.id = 1​​,有一个消费者:这个消费者要处理所有数据,即 3 个分区的数据。
  2. ​group.id = 2​​,有两个消费者:consumer 1消费者需处理 2个分区的数据,consumer2 消费者需处理 1个分区的数据
  3. ​group.id = 3​​,有三个消费者:消费者数量与分区数量相等,刚好每个消费者处理一个分区
  4. ​group.id = 4​​,有四个消费者:消费者数量 > 分区数量,第四个消费者则会处于空闲状态

标签:为什么,那么,消费者,分区,写入,Broker,Kafka,消息
From: https://blog.51cto.com/u_15733182/5920400

相关文章

  • kafka 简介与应用场景(一)
    kafka简介与应用场景(一)标签(空格分隔):kafka系列一:kafka简介二:kafka的相关组建三:kafka的架构四:kafka的应用场景一:kafka的简介:1.1kafka的简介Kafka是一......
  • 预编译SQL为什么能够防止SQL注入
    前言之前我一个搞网络安全的朋友问了我一个的问题,为啥用PreparedStatement预编译的SQL就不会有被SQL注入的风险?第一时间我联想到的是八股文中关于Mybatis的脚本......
  • 无代码:迈向数字化转型2.0的“不那么秘密的武器”
    数字达尔文主义让IT行业措手不及,技术的发展速度远远超过企业所能跟上的速度。数字化转型2.0的本质上是需要一支从根本上转变的劳动力队伍。业务用户通常想要创新,但他们不......
  • 为什么 egui 用立即模式?
    https://github.com/emilk/egui#why-immediate-mode 为什么立即模式egui是立即模式GUI库,与保留模式GUI库相对。保留模式和立即模式之间的区别最好用按钮的例子来说......
  • 恩泽都是那么的平等无私
    滋润万物,眺望这些我们无法达到的目标之时,如果时间能够返回,她对每一处的恩泽都是那么的平等无私,与自己有了过节的人,离开都是常见的,人为了一丝快乐而努力工作,也许是在一刹那,......
  • Scrapy入门到放弃01:我为什么选择Scrapy
    前言Scrapyiscoming!!在写了七篇爬虫基础文章之后,终于写到心心念念的Scrapy了。Scrapy开启了爬虫2.0的时代,让爬虫以一种崭新的形式呈现在开发者面前。在18年实习的时候......
  • Kafka 日志保留策略(Log Retention Policy)
    Kafka日志保留策略(LogRetentionPolicy)前言一两周前测试kafka,创建了topic:data-time,发布了一部分数据,测试kafka的发布和订阅均正常。一两周后,也就是现在,再次取订阅to......
  • kafka基础原理
    kafka基础原理1.topicKafka学习了数据库里面的设计,在里面设计了Topic(主题),这个东西类似于关系型数据库的表: 此时我需要获取CM的数据,那就直接监听TopicA即可。......
  • 实时数仓原来如此:Kafka+Flink+Hudi
    原来使用kafka消费者直接进行mysql数据同步,现在发现当时只考虑了数据的同步,对于后续数据的存储和使用没有考虑全面。面对大量流式数据,面向的是应用,数据同步之后,数据如何存......
  • 为什么Git远程仓库中要配置公钥?
    最近在使用阿里云效平台代码管理,首次使用新建仓库,使用SSH时需要配置公钥。之前也在GitHub、Gitee上配置过,每次都能正常使用,也没有思考过为什么要配置公钥。这次记录一下其......