消息压缩数据压缩显著地降低了磁盘占用或带宽占用从而有效地提升了 I/O密集型应用的性能。不过引入压缩同时会消耗额外的 CPU时钟周期因此压缩是 I/O性能和 CPU资源的平衡trade-off。Kafka自0.7.x版本便开始支持压缩特性——producer端能够将一批消息压缩成一条消息发送而 broker 端将这条压缩消息写入本地日志文件。当consumer 获取到这条压缩消息时它会自动地对消息进行解压缩还原成初始的消息集合返还给用户。压缩算法Kafka支持3种压缩算法GZIP、Snappy和LZ4默认情况下Kafka是不压缩消息的但用户可以通过设定producer端参数compression.type 来开启消息压缩即构造KafkaProducer的属性对象时进行设置。假定要设置使用Snappy压缩算法则设置方法如下props.put(compressiont.type,snappy);//或者props.put(ProducerConfig.COMPRESSION_TYPE,snappy);对 Kafka源代码熟悉的读者会发现 KafkaProducer.send方法逻辑的主要耗时都在消息压缩操作上因此妥善地调优压缩算法至关重要。大家可能觉得GZIP、Snappy和LZ4在实际环境中的表现各有千秋但对Kafka而言性能测试的结果出奇地一致即LZ4 Snappy GZIP多线程发送消息实际环境中只使用一个用户主线程通常无法满足所需的吞吐量目标因此需要构造多个线程或多个进程来同时给 Kafka集群发送消息。多线程单KafkaProducer实例 多线程多KafkaProducer实例多线程单KafkaProducer实例在全局构造一个KafkaProducer实例然后在多个线程中共享使用。由于KafkaProducer是线程安全的所以这种使用方式也是线程安全的。多线程多KafkaProducer实例在每个producer主线程中都构造一个KafkaProducer实例并且保证此实例在该线程中封闭thread confinement线程封闭是实现线程安全的重要手段之一如果是对分区数不多的 Kafka 集群而言比较推荐使用第一种方法即在多个producer 用户线程中共享一个 KafkaProducer 实例。若是对那些拥有超多分区的集群而言采用第二种方法具有较高的可控性方便producer的后续管理。上传kafka的安装包至/opt/software解压至: tar -zxvf kafka_2.12-2.4.1.tgz -C /opt/module/重命名: kafka-2.4.1配置环境变量:export KAFKA_HOME/opt/module/kafka-2.4.1export PATHPATH:PATH:PATH:KAFKA_HOME/bin5.修改配置文件:2各自配置完之后需要分别启动zk,或者自己整一个脚本启动kafka:kafka目录下启动rootsimon1 kafka-2.4.1]# bin/kafka-server-start.sh config/server.properties3台机器全部启动完毕
)
