kafka运行环境优化分析

kafka消费、生产性能问题分析及优化方法 这是一篇关于我个人遇到的kafka性能问题分析与解决方案,欢迎大家阅读和积极提提意见! 阅读详情

1.kafka高性能的特点及条件

kafka是一个高吞吐量分布式消息系统,并且提供了持久化。其高性能的有两个重要特点:(1)利用了磁盘连续读写性能远远高于随机读写的特点;(2)并发,将一个topic拆分多个partition。
要充分发挥kafka的性能,就需要满足这两个条件。linkedin的测试,就把这两个方面发挥到极致(参考

http://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines)

(1)磁盘的连续性

        要充分利用磁盘连续读写高性能的特点,就意味着要减少操作系统对磁盘的重新调度。kakfa内部的实现非常巧妙:
生产:   网络 —>  pagecache(内存) —>磁盘
消费:   磁盘 —> 网络          (使用sendfile将磁盘数据直接拷贝到网卡发送缓冲区)

 这样的设计使得,写磁盘的机会仅仅是pagecache需要flush到磁盘的时候;这样保证了大多数时候磁盘可以连续地读取,而且直   接复制到网卡,避免消费影响到生产(写入内存)。另外,使用文件系统pagecache而不是自建缓存,还利用pagecache对于 sendfile来说是透明的优势,也就是在没有消息堆积时,数据流动实际时pagecahe直接到网卡,减少磁盘io又保证及时消费。

(2)并发,将topic拆分多个partition

kafka读写的单位是partition,因此,将一个topic拆分为多个partition可以提高吞吐量。但是,这里有个前提,就是不同partition需       要位于不同的磁盘(可以在同一个机器)。如果多个partition位于同一个磁盘,那么意味着有多个进程同时对一个磁盘的多个文 件进行读写,使得操作系统会对磁盘读写进行频繁调度,也就是破坏了磁盘读写的连续性。

      在linkedlin的测试中,每台机器就加载了6个磁盘,并且不做raid,就是为了充分利用多磁盘并发读写,又保证每个磁盘连续读写的特性。
 

具体配置上,是将不同磁盘的多个目录配置到broker的log.dirs,例如
      log.dirs=/disk1/kafka-logs,/disk2/kafka-logs,/disk3/kafka-logs
      kafka会在新建partition的时候,将新partition分布在partition最少的目录上,因此,一般不能将同一个磁盘的多个目录设置到log.dirs

2.kafka在虚拟机环境的优化

        kafka高性能很大程度依赖于磁盘(文件系统)的连续读写,而在虚拟机环境中,文件系统一些不同的特点,因此做好这些优化很有必要。

(1)虚拟文件系统的特点

 通常,虚拟机不会直接使用物理磁盘(尽管可以)。多个物理磁盘或者raid阵列被宿主系统虚拟成一个大的磁盘,再分配各个虚拟机。对于虚拟文件系统来说,有2个特点比较重要
写优先。大多数虚拟文件系统为了保证磁盘数据的更新,都会一定程度保证写优先
非连续。对于可变大小的虚拟磁盘,通常再需要空间的时候再进行实际分配,造成逻辑上连续的文件,物理存储并不一定连续
高性能。为了支持多个虚拟机同时运行,合理的情况下配置的整体磁盘性能会比较高
不稳定。由于多个虚拟机同时运行的互相影响,可能会出现资源争夺导致的不稳定 

(2)kafka在虚拟机环境的优化

   首先是,多磁盘的并发的问题。不管怎么说,虚拟机环境至少剥夺了单个kafka同时使用多个磁盘的优势。也就意味着,在在同一个虚拟机,同一个topic,最好只有一个partition;当然,不同topic之间partition如果同时生产-消费也会互相影响,但不一定会同时在高峰(同个topic一定)。构建较大集群(在不同物理机)仍然能够保持并发优势。

   其次,写优先和不稳定也是需要考虑问题。如果多个topic同时写入,或者其他虚拟机抢占资源,可能会导致消费缓慢。因此,监控就显得特别重要,对于消费过慢的partition 暂停写入。由于pagecache默认会使用所有可用内存,增加内存可以减少flush到磁盘的次数,使得读取(消费)更加顺利。

另外,为了保证读写连续性,kafka自身及其他服务不要和log.dir共享磁盘。在美团虚拟机上,可以考虑将kafka 安装在系统磁盘, 数据盘(/opt)完全用于日志存储。

  总结一下,kafka在虚拟机环境的优化有三点:
      第一,组建较大集群,并保
证同一个topic的不同partition位于不同虚拟机(所以在不同的磁盘)
      第二,监控,对于消费过慢的partition(所在的broker),暂停写入(生产),等待消费
      第三,将kafka安装在系统盘,
数据盘(/opt)完全用于消息存储。数据盘上不安装其他服务

  不得不提的是,以上结论在美团办公云(读取200mb/s +)上测试有明显的表现;。但是,良好的配置可以提升稳定性,比如出现多个topic同时达到高峰,或者出现别的虚          拟机抢占资源的时候,通常更不容易出现故障。

(3) 内存相关设置

现在线上  默认的jvm内存堆分配较大(比如8g内存给jvm堆6g),导致系统其他可用内存比较小。pagecache是linux内核的低优先级缓存,在内存空间富裕的情况下才能获得较大的空间。并且kafka不自建缓存,堆空间需求也比较小。因此建议保留物理内存的1/2以上给系统,以便保证pagecache的分配。

关于jvm内存参数设置请参考:jvm调优总结

Golang 与 Kafka 的协同:优化消息处理流程 在实时数据处理场景(如电商大促订单、金融交易流水、日志分析)中,消息队列是系统的“交通枢纽”。Kafka 凭借高吞吐量、低延迟、可持久化的特性,成为最受欢迎的消息队列之一;而 Golang 凭借轻量级协程(Goroutine)和高效的并发模型,成为处理高并发任务的“利器”。Kafka 核心组件与 Golang 并发模型的匹配逻辑消息生产/消费的性能瓶颈与解决方案实际项目中的最佳实践(如批量处理、错误重试、监控调优) 阅读详情

相关推荐

基于Kafka+Spark的实时多维分析架构

Kafka解决“数据流转”:Spark的流处理需要“稳定的数据源”,而Kafka能提供“高吞吐、低延迟”的数据输入;Spark解决“实时计算”:Kafka本身不做计算,而Spark能对Kafka的流数据进行“多维聚合”(如按时间+地域计算销售额);生态兼容:Spark原生支持Kafka(通过),无需额外适配。Kafka:提供“高吞吐、低延迟”的数据流转;Spark:对Kafka的流数据进行“多维聚合”;:支持“低延迟查询”。这套架构的价值,在于让业务能“实时看到数据的价值”

软件工程实践的博客 1076

kafka-1-kafka运行异常的情况及解决方案

1 消费者consumer无法消费的异常 (1)异常现象: 服务器:record is corrupt(记录损坏)不明原因,有可能磁盘空间不足导致,导致消费者无法正常消费消息,卡在某一个offset不能继续消费。 (2)解决办法: 先停掉消费者程序,杀掉进程(不可关闭kafka服务)然后手动设置偏移量,跳过卡在的offset位置。 进入kafka目录,命令: #bin/kafka-consumer-groups.sh --bootstrap-server ip:9092 --group groupName

qq_20466211的博客 1万+

Kafka消息发送致接口超时原因分析与解决

借助apm、gc监控等定位到发券接口超时由kafka发送超时引起,经过分析后引出两个疑问:A、apm为什么未能精准采集kafka发送耗时,此疑问通过skywalking中插件源码得以解释;B、kafka发送超时的原因。通过梳理kafka client端发送流程中可能存在的阻塞点,服务端性能会影响客户端。在服务端不可控的情况,因此提出要将ack设置成0,同时引入额外的重试机制保证数据的完整性。

weixin_47095883的博客 1478

一种基于Spring-Kafka消费者动态启停方式的多环境切换的实现

生产环境有3套,分别是正式生产环境(A)、备份生产环境(B)和预生产环境§。这三套环境的代码是完全相同的,但部署了3套进程(3“套”而不是3“个”是因为每个环境都可能部署多节点),但数据库和中间件却是共用的。所以这3套环境中共用了同一个Kafka集群。

booynal的博客 2042

QLIB使用tushare更新每日行情

0. 介绍 qlib每日数据的源是yahoo,更新速度较慢并且不稳定。tushare每日行情是免费接口,速度较快。 1. 获取行情数据,保存为csv格式。 def GetDataFromTushare(self, today, fpath): pro = ts.pro_api() df = pro.daily(trade_date=today) for index, row in df.iterrows(): code = row['ts_code']

weixin_44177216的博客 2896

保姆级教程:用vxe-grid给管理后台加个「智能筛选」功能(支持模糊搜索/多选/范围查询)

本文提供了一份详细的Vxe-Grid智能筛选功能实现教程。通过自定义筛选器渲染,文章逐步指导开发者为后台管理系统添加支持模糊搜索、多选下拉和数值范围查询的智能筛选功能,并分享了性能优化与移动端适配等实战经验。

weixin_29021291的博客 536

kafka实战——如何选择线上环境

所谓线上部署环境,其实无非就是操作系统的选择,以及存储介质磁盘的选择,内存大小的选择,cpu的选择,网络带宽的选择。 除了操作系统意外,剩下的影响因子任何一个到了瓶颈,都相当于是短板,将会制约整体性能的发挥。 其实不光是部署kafka要考虑这些因素。部署其他的也是一样从这几个点出发,来考虑究竟应该如何选择环境。 如何择操作系统 这里简单的说一下kafka原理,之所以kafka有着极高的吞吐量,和kafka的写入速度以及读的速度有很大的关系。同样都是写磁盘,为啥kafka就能做到...

Angus 427

《AI编程实战:深度学习模型改进与系统部署》,改进专栏目录和介绍

专深度学习相关项目都写在本专栏,《一次订阅解锁全部,都有源码,永久观看》,包括车牌识别、股票预测、人脸识别、风格迁移、图像修复、图像超分辨重建、图像分割等任务,Web/PyQt系统实现。引入Transformer、Swin Transformer、DenseNet、ViT、ConvNeXt等算法实战,提供卷积改进,魔改对比实验,模型剪枝,模型蒸馏,模型量化,全网独家整合改进专栏,为不同领域的同学发表论文提供了大力支持。

在职AI算法工程师,擅长计算机视觉,YOLO目标检测、分割等,擅长web、pyqt界面可视化,好内容持续更新中,来这里跟大家一起学习,共同进步 3266

kafka性能调优

kafka是一个高吞吐量分布式消息系统,并且提供了持久化。其高性能的有两个重要特点: 利用了磁盘连续读写性能远远高于随机读写的特点; 并发,将一个topic拆分多个partition。 同一个ConsumerGroup内的Consumer和Partition在同一时间内必须保证是一对一的消费关系任意Partition在某一个时刻只能被一个Consumer Group内的一个Consumer消费(反过

#include<?> 3万+

整车电检工艺流程

本文是笔者在从事汽车行业智能制造领域过程,对于整车电检工艺流程的理解与总结。

qq_40664711的博客 1万+

物联网Node-Red开发教程-第6章 HTTP与Web服务

本章摘要(147字): 本章系统讲解了Node-RED中的HTTP节点应用,重点包括: 三大核心HTTP节点功能:http in(接收请求)、http response(返回响应)、http request(调用外部API) 详细演示了REST API开发流程,包括路径参数(req.params)处理和响应构造 提供了创建Hello World API、传感器数据接口等实用示例 涵盖HTTP方法特性、状态码设置及响应头配置等关键知识点 通过流程图和JSON配置直观展示节点连接方式,帮助快速掌握Web服务开发

shihui2003的博客 264

(十二)运行环境(加载、性能优化、安全)【这些会了,你就可以飞了】

运行环境运行环境网页加载过程加载资源的形式加载资源的过程渲染页面的过程性能优化、体验优化原则从何入手让加载更快让渲染更快安全XSS跨站请求攻击XXS攻击XSS预防XSRF跨站请求伪造XSRF攻击XSRF预防 运行环境 即浏览器 下载网页代码,渲染出页面,期间会执行若干JS 要保证代码在浏览器中,稳定且高效 网页加载过程 加载资源的形式 html形式 媒体文件,如图片、视频等 javascript、css等 加载资源的过程 DNS解析(域名服务解析):域名->IP地址,域名统一好记,IP地址不

lj1530562965的博客 590

55、宇宙微波背景辐射望远镜及其光学系统解析

本文详细解析了宇宙微波背景辐射(CMB)望远镜及其光学系统的设计与优化。内容涵盖折射与反射光学系统的特性、旁瓣控制技术、气球与地面观测系统的对比、探测器阵列的发展、光学系统设计流程以及不同观测场景下的光学系统选择。同时,文章展望了CMB望远镜光学系统的未来发展趋势,包括技术创新、多频段观测、国际合作与大型项目等。通过系统性的分析与对比,为CMB研究提供了全面的技术支持与理论基础。

f9g0h的博客 142

apache kafka技术分享系列(目录索引)

kafka开发与管理: 1)apache kafka消息服务 2)kafak安装与使用 3)apache kafka中server.properties配置文件参数说明 4)apache kafka中topic级别配置 5)Apache kafka客户端开发-java 6)kafka的ZkUtils类的java版本部分代码

Mirage520的专栏 1247

读懂 ABAP CDS 注解的直接、继承与派生

本文系统梳理了ABAP CDS注解的评估逻辑,重点解析直接注解(Direct)、继承注解(Inherited)和派生注解(Derived)的差异及其在CL_DD_DDL_ANNOTATION_SERVICE中的处理方式。通过视图注解@Metadata.ignorePropagatedAnnotations可调控注解传播行为,避免下游语义影响上层视图。文章还提供了基于标准表的完整示例(包含底层视图、消费视图和ABAP报告程序),帮助开发者在实际系统中验证三层注解的叠加效果与阻断机制。关键点包括:派生注解的数据

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 244

廖雪峰Python教程[完整版]

廖雪峰的python教程整理的,已经排好版了,而且还是完整的,适合小白

Kafka 消费积压情况分析与优化策略

在 Kafka 中,消息从 Producer 发送到 Broker 后,会被存储在特定的 Partition 中。消费者组(Consumer Group)中的 Consumer 负责从这些 Partition 中拉取消息并进行处理。然而,在某些情况下,Consumer 可能无法及时处理所有消息,从而导致消息积压(Lag)。消息积压不仅会影响系统的实时性,还可能导致数据丢失或处理延迟。因此,理解如何监控和管理消费积压是 Kafka 运维中的一个重要课题。

用文字记录技术,用分享回馈社区,用坚持见证成长 1006

假人有限元模型

假人模型,车辆碰撞假人有限元模型,适合做乘员安全的研究者利用

Kafka集群实战与原理分析线上问题优化

Message Queue(MQ),消息队列中间件。很多人都说:MQ 通过将消息的发送和接收分离来实现应用程序的异步和解偶,这个给人的直觉是——MQ 是异步的,用来解耦的,但是这个只是 MQ 的效果而不是目的。MQ 真正的目的是为了通讯,屏蔽底层复杂的通讯协议,定义了一套应用层的、更加简单的通讯协议。一个分布式系统中两个模块之间通讯要么是 HTTP,要么是自己开发的 TCP,但是这两种协议其实都是原始的协议。

qq_23045563的博客 783

SAP B1中文培訓教材_SDK

公司内部培训资料,对开发工具 ,DIAPI, UIAPI,Add-ON有详细解说

精雕软件(JDpaint) 5.5 绿色版

精雕软件(JDpaint) 5.5 绿色版精雕软件(JDpaint) 5.5 绿色版精雕软件(JDpaint) 5.5 绿色版

Kafka JVM 内存使用率告警信息分析与优化建议

Kafka 是一个高吞吐、分布式的消息队列系统,其本质上是运行在 Java 虚拟机(JVM)上的 Java 应用。因此,Kafka 的运行效率、性能稳定性与 JVM 内存管理密切相关。在日常运维中,Kafka 的 JVM 内存使用率是一个重要的监控指标。当内存使用率持续偏高(如超过 80%),可能意味着系统运行接近资源瓶颈,存在服务抖动甚至崩溃风险。Kafka JVM 内存使用率告警信息分析与优化建议,内容清晰完整,适合用于知识库或故障文档中长期留存。来调整 Kafka 实例的堆内存大小。

喝醉酒的小白 1481

Kafka高性能集群部署与优化

Kafka是由Apache Software Foundation开发的一个分布式流处理平台,源代码以Scala编写。Kafka最初是由LinkedIn公司开发的,于2011年成为Apache的顶级项目之一。高吞吐量:Kafka每秒可以处理数百万条消息。持久化:数据存储在硬盘上,支持数据可靠性和持久性。分布式:Kafka集群可以在多台服务器上运行,提供高可用性和容错性。多语言支持:Kafka提供多种编程语言的客户端API,包括Java、Python、Go等。

BXA 3547

Kafka 主题分区策略的优化

Kafka 提供了多种分区策略,默认采用基于消息键(Key)的分区方式(DefaultPartitioner)。这种策略确保具有相同键的消息始终被路由到同一个分区中,从而保持消息顺序。无键分区(No Key Partitioning):消息没有指定键时,Kafka 会使用轮询(Round Robin)的方式将消息均匀分配给各个分区。自定义分区器(Custom Partitioner):用户可以根据业务需求编写自定义逻辑,灵活控制消息的分发方式。Kafka 的分区策略是影响系统性能的重要因素之一。

2501_91229450的博客 1662

去哪儿kafka优化案例

网络方面:当前集群网卡平均出口流量峰值已经超过4G,单机最大会超过8G,如果流量继续上升,网卡会成为新的瓶颈,我们准备把10G网卡提升到25G或改为双通道20G。磁盘方面:当前集群的主流磁盘是3T,高峰时期磁盘使用率集群均值已经达到60%,单机已经达到85%,我们准备每台机器再添加一块3T盘来扩展存储能力和IO的压力。对于磁盘IO的影响,线上我们都是用单盘提供服务,如果我们改用双盘,两个盘理论上是单盘IO两倍的性能,但是加盘之后,同样的压测数据,对闲置率没有影响。内存监控,内存没有明显的变化。

weixin_51981189的博客 1636

Kafka Native:高效的原生Kafka解决方案

Kafka Native:高效的原生Kafka解决方案 项目介绍 Kafka Native 是一个使用 Quarkus 和 GraalVM 将 Kafka broker 编译为原生应用的解决方案。它旨在通过提供一种轻量级、高性能的方法来运行 Kafka 服务器,从而优化资源使用并提升启动速度。Kafka Native 适用于需要高性能和低延迟的场景,特别适合在容器化和微服务架构中使用。 项目技术分...

gitblog_00299的博客 1273
上一篇: apache Kafka Replication设计分析
下一篇: kafka server部署配置优化
wrr-cat
博客等级 码龄9年 128粉丝 302原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值