kafka分区数过多引发的弊端

标签: | 发表时间:2020-05-27 10:00 | 作者:
出处:https://mp.weixin.qq.com

上篇文章我们了解到,如果一个 topic分区越多,理论上整个集群所能达到的吞吐量就越大。那么,分区数越多就越好吗?显然不是。今天我们来聊下 kafka在分区数过多的情况下,会带来哪些弊端。 

内存开销

客户端 producer有个参数 batch.size默认为 16KB。它会为每个分区缓存消息,一旦批次数满了后,将消息批量发出。一般来说,这个设计是用于提升吞吐性能的。但是由于这个参数是 partition级别的,如果分区数越多,这部分缓存所需的内存占用也会越多。

假如有 10000 个分区,按照默认配置,这部分缓存就要占用约 157MB 的内存。而 consumer端呢?抛开拉取数据所需的内存不说,单说线程的开销。如果还是 10000 个分区,同时 consumer线程数要匹配分区数的话(大部分情况下是最佳的消费吞吐量配置),那么在 consumer client就要创建 10000 个线程,也需要创建大约 10000 个 Socket去获取分区数据,这里面的线程切换的开销本身就已经不容小觑了。

服务器端的开销也不小,如果阅读 kafka源码的话就会发现,服务器端的很多组件在内存中维护了 partition级别的缓存,比如 controllerFetcherManager等,因此分区数越多,这种缓存的成本就越大。

文件句柄开销

每个分区在文件系统上会对应一个目录,用于存储维护 kafka数据日志。该目录通常会有 3 个文件, .log.index.timeindex,对应 kafka的日志数据文件和索引文件(老版本 kafka 没有 timeindex文件)。 broker会一直保持打开这 3 个文件句柄( file handler)。因此,如果分区数越多,所需要保持打开状态的文件句柄数也就越多,最终可能会突破单台 brokerulimit -n的上限。

链路延迟

kafka的链路延迟也就是 producer端发布消息到 consumer端接收消息所需要的时间。 kafka只有在消息提交之后,才会将消息暴露给消费者,期间消息需要在 in-sync副本列表中完成同步复制,这是耗时的主要部分。默认情况下,每个 broker从其他 broker节点进行数据副本同步时,该节点只会为此分配一个线程,该线程需要完成该 broker上所有 partition数据的复制。我查到数据显示,将 1000 个 partition从一个 broker到另一个 broker所需时间延迟约为 20ms,这意味着链路延迟至少是 20ms。这样的延迟对于一些实时业务来说可能就有些长了。

SLA

kafka是通过副本机制(replica)提供高可用,来保障 SLA的。每个 partition都会有多个副本,每个副本分别存在于不同的 broker。所有的数据副本中,有一个数据副本被选举为 leader,负责处理 producerconsumer请求。其他的数据副本为 follower,由 Kafka controller负责保证与 leader的同步。

leader不可用时,会从 follower中重新选出新的 leader,这中间会有短暂的不可用时间,虽然大部分情况下可能只是几毫秒级别。但是假如,一个 2 节点的 kafka集群中存在 2000 个 partition,每个 partition拥有 2 个副本。当其中一个 broker意外宕机,所有 1000 个 partition同时变得不可用。假设每一个 partition恢复时间是 5ms,那么 1000 个 partition的恢复时间将会花费 5 秒钟,这可能对用户来说就会有一个明显的感知了。如果宕机的是 controller节点,不可用时间将会更严重。

上述问题,通常情况下,都可以通过扩容集群来缓解,毕竟在不考虑成本的情况下,堆机器可以解决 90%的问题。当然正常情况,还是得在合理的成本范围内,进行合理的规划和调优,上述弊端一般都是能在可控范围内的。

相关 [kafka 分区] 推荐:

kafka分区数过多引发的弊端

- -
topic分区越多,理论上整个集群所能达到的吞吐量就越大. kafka在分区数过多的情况下,会带来哪些弊端. batch.size默认为 16KB. 它会为每个分区缓存消息,一旦批次数满了后,将消息批量发出. 一般来说,这个设计是用于提升吞吐性能的. partition级别的,如果分区数越多,这部分缓存所需的内存占用也会越多.

kafka监控之kafka-run-class.sh

- - 开源软件 - ITeye博客
kafka自带了很多工具类,在源码kafka.tools里可以看到:. 这些类该如何使用呢,kafka的设计者早就为我们考虑到了,在${KAFKA_HOME}/bin下,有很多的脚本,其中有一个kafka-run-class.sh,通过这个脚本,可以调用其中的tools的部分功能,如调用kafka.tools里的ConsumerOffsetChecker.scala,.

闲扯kafka mq

- - 开源软件 - ITeye博客
本文主要讲解关于kafka mq的设计思想及个人理解. 关于kafka的详细信息,大家可以参考官网的文献 http://kafka.apache.org/documentation.html这是一篇相当不错的文章,值得仔细研读. 第一个问题:消息队列(Message Queue)是干嘛用的. 首先,要对消息队列有一个基本的理解.

Kafka优化

- - ITeye博客
配置优化都是修改server.properties文件中参数值. 1.网络和io操作线程配置优化. # broker处理消息的最大线程数. # broker处理磁盘IO的线程数. 一般num.network.threads主要处理网络io,读写缓冲区数据,基本没有io等待,配置线程数量为cpu核数加1.

Kafka Connect简介

- - 鸟窝
Kafka 0.9+增加了一个新的特性 Kafka Connect,可以更方便的创建和管理数据流管道. 它为Kafka和其它系统创建规模可扩展的、可信赖的流数据提供了一个简单的模型,通过 connectors可以将大数据从其它系统导入到Kafka中,也可以从Kafka中导出到其它系统. Kafka Connect可以将完整的数据库注入到Kafka的Topic中,或者将服务器的系统监控指标注入到Kafka,然后像正常的Kafka流处理机制一样进行数据流处理.

kafka consumer group offset

- - 开源软件 - ITeye博客
     kafka0.9及以前版本kafka offset 保存在zookeeper, 因频繁读写zookeeper性能不高;从0.10开始,主题分区offset存储于kafka独立主题中.     管理监控kafka主题及分区offset至关重要,原网上很开源流行工具KafkaOffsetMonitor、kafka-manager,旧版offset保存于zookeeper,kafka consumer无相应API,从kafka0.10.1.1以后提供相应API读取主题分区offset(也可以调用KafkaClient API,kafka管理API由scala语言编写).

Kafka设计解析(二):Kafka High Availability (上)

- -
Kafka在0.8以前的版本中,并不提供High Availablity机制,一旦一个或多个Broker宕机,则宕机期间其上所有Partition都无法继续提供服务. 若该Broker永远不能再恢复,亦或磁盘故障,则其上数据将丢失. 而Kafka的设计目标之一即是提供数据持久化,同时对于分布式系统来说,尤其当集群规模上升到一定程度后,一台或者多台机器宕机的可能性大大提高,对Failover要求非常高.

GitHub - andreas-schroeder/kafka-health-check: Health Check for Kafka Brokers.

- -
At AutoScout24, to keep the OS up to date of our clusters running on AWS, we perform regular in-place rolling updates. As we run immutable servers, we terminate each broker and replace them with fresh EC2 instances (keeping the previous broker ids).

Kafka编程实例

- - CSDN博客云计算推荐文章
    Producer是一个应用程序,它创建消息并发送它们到Kafka broker中. 这些producer在本质上是不同. 比如,前端应用程序,后端服务,代理服务,适配器对于潜在的系统,Hadoop对于的Producer. 这些不同的Producer能够使用不同的语言实现,比如java、C和Python.

kafka集群安装

- - 互联网 - ITeye博客
kafka是LinkedIn开发并开源的一个分布式MQ系统,现在是Apache的一个孵化项目. 在它的主页描述kafka为一个高吞吐量的分布式(能将消息分散到不同的节点上)MQ. 在这片博文中,作者简单提到了开发kafka而不选择已有MQ系统的原因. Kafka仅仅由7000行Scala编写,据了解,Kafka每秒可以生产约25万消息(50 MB),每秒处理55万消息(110 MB).