美文网首页
Kafka优化

Kafka优化

作者: CoderZS | 来源:发表于2020-07-19 11:18 被阅读0次

一 , broker优化:

  1. 优化处理消息的最大线程数 默认是3 可以调成CPU数+1

  2. broker处理磁盘IO线程数 CUP数*2

  3. 调整log的文件刷盘策略 10000条或者1秒

  4. 日志保存策略调整为72小时 不建议过多

  5. 副本机制调整为2-3

  6. 根据业务量调整合适的partition数量

二,Producer优化:

  1. 调整未发送出去消息的缓冲区大小

  2. 默认发送不压缩,可以配置合适的压缩方式(Snappy)

三, Consumer优化:

1.启动consumer的线程数适当的增加可以提高并发度 与分区数一致

Kafka内存:默认一个G可以适当的调高一些,一般不建议超过6个G

消息压缩

压缩的是使用时间换空间的思想,具体来说就是使用CPU的时间去换取空间或网络I/0传输量。

怎么压缩?

kafka是如何压缩的消息的呢?目前,kafka共有俩大消息格式,社区分别称之为V1版本和V2版本。V2B版本是在kafka0.11.0.0中正式引入的。

不论哪个版本,kafka的消息分为俩层:消息集合(message set)以及消息(message)。一个消息集合中包含若干条日志项(record item),而日志项才是真正封装消息的地方。kafka底层的消息日志由一系列消息集合日志项组成。kafka通常不会直接操作具体的一条条消息,他总是在消息集合这个层面上进行写入操作。

那么社区引入V2版本的目的是什么呢?主要是针对V1版本做了一些修改,先介绍一个,就是把消息的公共部分抽取出来放到外层消息集合里面,这样就不用每条消息都保存这些信息了。

V2版本还有一个和压缩息息相关的改进,就是保存压缩消息的方法发生了改变。之前V1版本中保存压缩消息的方法是把多条消息进行压缩后保存到外层消息字段中;而V2版本的做法是对整个消息集合进行压缩。显然后者应该比前者有更好的性能。比较如下:


图片.png

何时压缩?

kafka中,压缩可能发生在俩个地方:生产者和Broker端.

生产者程序中配置compression.type参数即表示启用指定类型的压缩算法(比如snappy)

在生产者端启用压缩是很自然的想法,那么为什么我说在Broker端也可以进行压缩呢?其实大部分情况下Broker从Producer端接受消息后仅仅是原封不动的保存而不会对其进行任何修改,但这里的”大部分情况“也是要满足一定条件的。有俩种例外的情况就可能让Broker重新压缩消息。

情况一:Broker端指定了和Producer端不同的压缩算法。

当Broker和Product指定的压缩算法不一致时,Broker接收到Product消息后解压之后再用Broker指定的算法在压缩,这样就会到导致CPU压力飙升。kafka服务端有指定压缩算法的参数compression.type,这个参数默认是product意思是指定和product一样的压缩算法。

情况二:Broker端发生了消息格式转换

所谓的消息格式转换只要是为了兼容老版本的消费者程序。由于kafka现在有俩种消息格式V1版本和V2版本,为了兼容老版本的格式,Broker端会对新版消息执行想老版本格式的转换。这个过程会涉及消息的解压缩和重新压缩。这种情况下对性能影响很大,除了这里的压缩之外,它还会让kafka失去引以为豪的Zero Copy (零拷贝)特性。

何时解压?

通常来说解压缩发生在消费者程序中,也就是说Produc发送压缩消息到Broker后,Broker照单全收并原样保存起来。当Consumer程序请求这部分消息时,Broker依然原样发送出去,当消息到达Consumer端后,由Consumer自行解压缩还原成之前的消息。

那么现在问题来了,Consumer怎么知道这些消息是用何种算法压缩的呢?其实答案就在消息中。kafka会将启用了那种压缩算法封装进行消息集合中,这样Consumer收到消息集合时,它自然知道了这些消息使用的是那种算法。

压缩解压缩过程:Product端压缩----Broker端保持----Consumer端解压缩

除了在Consumer端解压缩,Broker端也会进行解压缩。注意了,这和前面提到的消息格式转换时发生的解压缩是不同的场景。每个压缩过的消息集合在Broker端写入时都要发生解压缩操作,目的就是为了对消息进行各种验证。但是必须承认这种解压缩对Broker端性能是有一定影响的,特别是对CPU使用率而言。

各种压缩算法对比

在kafka2.1.0版本之前,kafka支持3种压缩算法:GZIP、Snappy和LZ4。从2.1.0开始,kafka正式支持Zstandard算法(简称:zstd)。这是一个Facebook开源的一个压缩算法,能够提供超高的压缩比(compression ratio)

压缩算法的优劣又来个重要的指标:压缩比和吞吐量

下面是Facebook提供的压缩算法对比图:


图片.png

相关文章

  • Kafka 最佳实践

    Kafka 基本配置及性能优化 这里主要是 Kafka 集群基本配置的相关内容。 硬件要求 Kafka 集群基本硬...

  • Kafka优化

    一 , broker优化: 优化处理消息的最大线程数 默认是3 可以调成CPU数+1 broker处理磁盘IO线程...

  • kafka之网络模型总结

    弄清楚kafka的网络模型原理,能很好的帮助理解和优化kafka服务。kafka底层的网络通信,没有使用第三方rp...

  • kafka性能优化

    1.partition数量配置 partition数量由topic的并发决定,并发少则1个分区就可以,并发越高,分...

  • kafka优化笔记

    1 mq的作用 解耦、异步、削峰填谷 2 kafka架构 1)Producer :消息生产者,就是向 kafka ...

  • Kafka broker 调优

    这些优化可以去官网看,官网有说明 Kafka 的架构这里就不多做介绍了,直接步入正题。 这里主要是 Kafka 集...

  • (10)Consumer多线程实例(2)

    Kafka 0.9推了Java版本consumer(替换Scala版本),优化coordinator摆脱对zk依赖...

  • 美团关于大数据技术的文章

    Spark性能优化指南——基础篇Spark性能优化指南——高级篇Spark在美团的实践Kafka文件存储机制那些事...

  • flume-ng添加自定义拦截器

    业务场景:收集nginx日志中个别信息进入kafka,为了避免kafka压力过大,这里优化了两点 刷选掉不需要分析...

  • Elasticsearch在日志分析领域应用和运维实践

    主要讲述了: 基于ELK + Kafka 的日志分析系统 Elasticsearch 优化经验 Elasticse...

网友评论

      本文标题:Kafka优化

      本文链接:https://www.haomeiwen.com/subject/zaelkktx.html