分布式微服务系统架构第174集:kafka硬件配置

加群联系作者vx:xiaoda0423

仓库地址:https://webvueblog.github.io/JavaPlusDoc/

https://1024bat.cn/

https://github.com/webVueBlog/fastapi_plus

https://webvueblog.github.io/JavaPlusDoc/

点击勘误issues,哪吒感谢大家的阅读

kafka节点,broker核心参数配置,服役新节点,退役旧节点,核心参数配置,再平衡,事务,提高吞吐量,数据精准一次,合理设置分区,单条日志大于1M,服务器挂了,压力测试集群。

Kafka硬件配置选择

1.1 场景说明

100万日活,每人每天100条日志,每天总共的日志条数是100万 * 100条 = 1亿条。

1亿/24小时/60分/60秒 = 1150条/每秒钟。

每条日志大小:0.5k - 2k(取1k)。

1150条/每秒钟 * 1k ≈ 1m/s 。

高峰期每秒钟:1150条 * 20倍 = 23000条。

每秒多少数据量:20MB/s。

服务器台数选择

服务器台数= 2 * (生产者峰值生产速率 * 副本 / 100) + 1

= 2 * (20m/s * 2 / 100) + 1

= 3台

建议3台服务器。

磁盘选择

kafka底层主要是顺序写,固态硬盘和机械硬盘的顺序写速度差不多。

建议选择普通的机械硬盘。

每天总数据量:1亿条 * 1k ≈ 100g

100g * 副本2 * 保存时间3天 / 0.7 ≈ 1T

建议三台服务器硬盘总大小,大于等于1T。

内存选择

Kafka内存组成:堆内存 + 页缓存

1)Kafka堆内存建议每个节点:10g ~ 15g

在kafka-server-start.sh中修改

go 复制代码
if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then

    export KAFKA_HEAP_OPTS="-Xmx10G -Xms10G"

fi
go 复制代码
查看Kafka进程号

[@hadoop102 kafka]$ jps

**2321** Kafka

5255 Jps

1931 QuorumPeerMain

根据Kafka进程号,查看Kafka的GC情况

go 复制代码
@hadoop102 kafka]$ jstat -gc **2321** 1s 10

 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   

 0.0   7168.0  0.0   7168.0 103424.0 60416.0  1986560.0   148433.5  52092.0 46656.1 6780.0 6202.2     13    0.531   0      0.000    0.531

 0.0   7168.0  0.0   7168.0 103424.0 60416.0  1986560.0   148433.5  52092.0 46656.1 6780.0 6202.2     13    0.531   0      0.000    0.531

 0.0   7168.0  0.0   7168.0 103424.0 60416.0  1986560.0   148433.5  52092.0 46656.1 6780.0 6202.2     13    0.531   0      0.000    0.531

 0.0   7168.0  0.0   7168.0 103424.0 60416.0  1986560.0   148433.5  52092.0 46656.1 6780.0 6202.2     13    0.531   0      0.000    0.531

 0.0   7168.0  0.0   7168.0 103424.0 60416.0  1986560.0   148433.5  52092.0 46656.1 6780.0 6202.2     13    0.531   0      0.000    0.531

 0.0   7168.0  0.0   7168.0 103424.0 61440.0  1986560.0   148433.5  52092.0 46656.1 6780.0 6202.2     13    0.531   0      0.000    0.531

 0.0   7168.0  0.0   7168.0 103424.0 61440.0  1986560.0   148433.5  52092.0 46656.1 6780.0 6202.2     13    0.531   0      0.000    0.531

 0.0   7168.0  0.0   7168.0 103424.0 61440.0  1986560.0   148433.5  52092.0 46656.1 6780.0 6202.2     13    0.531   0      0.000    0.531

 0.0   7168.0  0.0   7168.0 103424.0 61440.0  1986560.0   148433.5  52092.0 46656.1 6780.0 6202.2     13    0.531   0      0.000    0.531

 0.0   7168.0  0.0   7168.0 103424.0 61440.0  1986560.0   148433.5  52092.0 46656.1 6780.0 6202.2     13    0.531   0      0.000    0.531

参数说明:

S0C:第一个幸存区的大小; S1C:第二个幸存区的大小

S0U:第一个幸存区的使用大小; S1U:第二个幸存区的使用大小

EC:伊甸园区的大小; EU:伊甸园区的使用大小

OC:老年代大小; OU:老年代使用大小

MC:方法区大小; MU:方法区使用大小

CCSC:压缩类空间大小; CCSU:压缩类空间使用大小

YGC:年轻代垃圾回收次数; YGCT:年轻代垃圾回收消耗时间

FGC:老年代垃圾回收次数; FGCT:老年代垃圾回收消耗时间

GCT:垃圾回收消耗总时间;

根据Kafka进程号,查看Kafka的堆内存

go 复制代码
@hadoop102 kafka]$ jmap -heap 2321

Attaching to process ID 2321, please wait...

Debugger attached successfully.

Server compiler detected.

JVM version is 25.212-b10

 

using thread-local object allocation.

Garbage-First (G1) GC with 8 thread(s)

 

Heap Configuration:

   MinHeapFreeRatio         = 40

   MaxHeapFreeRatio         = 70

   MaxHeapSize              = 2147483648 (2048.0MB)

   NewSize                  = 1363144 (1.2999954223632812MB)
MaxNewSize               = 1287651328 (1228.0MB)

   OldSize                  = 5452592 (5.1999969482421875MB)

   NewRatio                 = 2

   SurvivorRatio            = 8

   MetaspaceSize            = 21807104 (20.796875MB)

   CompressedClassSpaceSize = 1073741824 (1024.0MB)

   MaxMetaspaceSize         = 17592186044415 MB

   G1HeapRegionSize         = 1048576 (1.0MB)

 

Heap Usage:

G1 Heap:

   regions  = 2048

   capacity = 2147483648 (2048.0MB)

   used     = 246367744 (234.95458984375MB)

   free     = 1901115904 (1813.04541015625MB)

   11.472392082214355% used

G1 Young Generation:

Eden Space:

   regions  = 83

   capacity = 105906176 (101.0MB)

   used     = 87031808 (83.0MB)

   free     = 18874368 (18.0MB)

   82.17821782178218% used

Survivor Space:

   regions  = 7

   capacity = 7340032 (7.0MB)

   used     = 7340032 (7.0MB)

   free     = 0 (0.0MB)

   100.0% used

G1 Old Generation:

   regions  = 147

   capacity = 2034237440 (1940.0MB)

   used     = 151995904 (144.95458984375MB)

   free     = 1882241536 (1795.04541015625MB)

   7.471886074420103% used

 

13364 interned Strings occupying 1449608 bytes.

页缓存:页缓存是Linux系统服务器的内存。我们只需要保证1个segment(1g)中25%的数据在内存中就好。

每个节点页缓存大小 =(分区数 * 1g * 25%)/ 节点数。例如10个分区,页缓存大小=(10 * 1g * 25%)/ 3 ≈ 1g

建议服务器内存大于等于11G。

CPU选择****

num.io.threads = 8 负责写磁盘的线程数,整个参数值要占总核数的50%。

num.replica.fetchers = 1 副本拉取线程数,这个参数占总核数的50%的1/3。

num.network.threads = 3 数据传输线程数,这个参数占总核数的50%的2/3。

建议32个cpu core。

网络选择

网络带宽 = 峰值吞吐量 ≈ 20MB/s 选择千兆网卡即可。

100Mbps单位是bit;10M/s单位是byte ; 1byte = 8bit,100Mbps/8 = 12.5M/s。

一般百兆的网卡(100Mbps )、千兆的网卡(1000Mbps)、万兆的网卡(10000Mbps)。

Kafka生产者

3.1.1 Updating Broker Configs

From Kafka version 1.1 onwards, some of the broker configs can be updated without restarting the broker. See the Dynamic Update Mode column in Broker Configs for the update mode of each broker config.

read-only: Requires a broker restart for update

per-broker: May be updated dynamically for each broker

cluster-wide: May be updated dynamically as a cluster-wide default.

参数名称 描述
bootstrap.servers 生产者连接集群所需的broker地址清单。例如hadoop102:9092,hadoop103:9092,hadoop104:9092,可以设置1个或者多个,中间用逗号隔开。注意这里并非需要所有的broker地址,因为生产者从给定的broker里查找到其他broker信息。
参数名称 描述
buffer.memory RecordAccumulator缓冲区总大小,默认32m。
batch.size 缓冲区一批数据最大值,默认16k。适当增加该值,可以提高吞吐量,但是如果该值设置太大,会导致数据传输延迟增加。
linger.ms 如果数据迟迟未达到batch.size,sender等待linger.time之后就会发送数据。单位ms,默认值是0ms,表示没有延迟。生产环境建议该值大小为5-100ms之间。
compression.type 生产者发送的所有数据的压缩方式。默认是none,也就是不压缩。支持压缩类型:none、gzip、snappy、lz4和zstd。
参数名称 描述
acks 0:生产者发送过来的数据,不需要等数据落盘应答。1:生产者发送过来的数据,Leader收到数据后应答。-1(all):生产者发送过来的数据,Leader+和isr队列里面的所有节点收齐数据后应答。默认值是-1,-1和all是等价的。
参数名称 描述
enable.idempotence 是否开启幂等性,默认true,表示开启幂等性。
go 复制代码
// 1初始化事务

void initTransactions();

 

// 2开启事务

void beginTransaction() throws ProducerFencedException;

 

// 3在事务内提交已经消费的偏移量(主要用于消费者)

void sendOffsetsToTransaction(Map<TopicPartition, OffsetAndMetadata> offsets,

                              String consumerGroupId) throws ProducerFencedException;

 

// 4提交事务

void commitTransaction() throws ProducerFencedException;

 

// 5放弃事务(类似于回滚事务的操作)

void abortTransaction() throws ProducerFencedException;
参数名称 描述
enable.idempotence 是否开启幂等性,默认true,表示开启幂等性。
max.in.flight.requests.per.connection 允许最多没有返回ack的次数,默认为5,开启幂等性要保证该值是 1-5的数字。
参数名称 描述
replica.lag.time.max.ms ISR中,如果Follower长时间未向Leader发送通信请求或同步数据,则该Follower将被踢出ISR。该时间阈值,默认30s。
auto.leader.rebalance.enable 默认是true。 自动Leader Partition 平衡。建议关闭。
leader.imbalance.per.broker.percentage 默认是10%。每个broker允许的不平衡的leader的比率。如果每个broker超过了这个值,控制器会触发leader的平衡。
leader.imbalance.check.interval.seconds 默认值300秒。检查leader负载是否平衡的间隔时间。
log.segment.bytes Kafka中log日志是分成一块块存储的,此配置是指log日志划分 成块的大小,默认值1G。
log.index.interval.bytes 默认4kb,kafka里面每当写入了4kb大小的日志(.log),然后就往index文件里面记录一个索引。
log.retention.hours Kafka中数据保存的时间,默认7天。
参数名称 描述
fetch.max.bytes 默认Default: 52428800(50 m)。消费者获取服务器端一批消息最大的字节数。如果服务器端一批次的数据大于该值(50m)仍然可以拉取回来这批数据,因此,这不是一个绝对最大值。一批次的大小受message.max.bytes (broker config)or max.message.bytes (topic config)影响。
max.poll.records 一次poll拉取数据返回消息的最大条数,默认是500条

如何提升吞吐量

如何提升吞吐量?

1 )提升生产吞吐量

(1)buffer.memory:发送消息的缓冲区大小,默认值是32m,可以增加到64m。

(2)batch.size:默认是16k。如果batch设置太小,会导致频繁网络请求,吞吐量下降;如果batch太大,会导致一条消息需要等待很久才能被发送出去,增加网络延时。

(3)linger.ms,这个值默认是0,意思就是消息必须立即被发送。一般设置一个5-100毫秒。如果linger.ms设置的太小,会导致频繁网络请求,吞吐量下降;如果linger.ms太长,会导致一条消息需要等待很久才能被发送出去,增加网络延时。

(4)compression.type:默认是none,不压缩,但是也可以使用lz4压缩,效率还是不错的,压缩之后可以减小数据量,提升吞吐量,但是会加大producer端的CPU开销。

2 )增加分区

3 )消费者提高吞吐量

(1)调整fetch.max.bytes大小,默认是50m。

(2)调整max.poll.records大小,默认是500条。

4)增加下游消费者处理能力

合理设置分区数

(1)创建一个只有1个分区的topic。

(2)测试这个topic的producer吞吐量和consumer吞吐量。

(3)假设他们的值分别是Tp和Tc,单位可以是MB/s。

(4)然后假设总的目标吞吐量是Tt,那么分区数 = Tt / min(Tp,Tc)。

例如:producer吞吐量 = 20m/s;consumer吞吐量 = 50m/s,期望吞吐量100m/s;

分区数 = 100 / 20 = 5分区

分区数一般设置为:3-10个

分区数不是越多越好,也不是越少越好,需要搭建完集群,进行压测,再灵活调整分区个数。

参数名称 描述
message.max.bytes 默认1m,broker端接收每个批次消息最大值。
max.request.size 默认1m,生产者发往broker每个请求消息最大值。针对topic级别设置消息体的大小。
replica.fetch.max.bytes 默认1m,副本同步数据,每个批次消息最大值。
fetch.max.bytes 默认Default: 52428800(50 m)。消费者获取服务器端一批消息最大的字节数。如果服务器端一批次的数据大于该值(50m)仍然可以拉取回来这批数据,因此,这不是一个绝对最大值。一批次的大小受message.max.bytes (broker config)or max.message.bytes (topic config)影响。

服务器挂了

在生产环境中,如果某个Kafka节点挂掉。

正常处理办法:

(1)先尝试重新启动一下,如果能启动正常,那直接解决。

(2)如果重启不行,考虑增加内存、增加CPU、网络带宽。

(3)如果将kafka整个节点误删除,如果副本数大于等于2,可以按照服役新节点的方式重新服役一个新节点,并执行负载均衡。

集群压力测试

1 )Kafka 压测

用Kafka官方自带的脚本,对Kafka进行压测。

l 生产者压测:kafka-producer-perf-test.sh

l 消费者压测:kafka-consumer-perf-test.sh

相关推荐
天將明°4 小时前
状态模式指南:对象状态变化的优雅管理
c语言·架构·设计规范
权^4 小时前
Hadoop 保姆级搭建手册:突出教程的细致和易上手
大数据·hadoop·分布式
歪歪1004 小时前
介绍一下SQLite的基本语法和常用命令
数据库·sql·架构·sqlite
love530love4 小时前
2025 PyCharm IDE 社区版与专业版合并后,新手该如何安装?(附 Toolbox 图形化安装教程)
ide·人工智能·windows·python·架构·pycharm·github
赴前尘5 小时前
kafka 2.12_3.9.1 版本修复 Apache Commons BeanUtils 访问控制错误漏洞(CVE-2025-48734)
分布式·kafka·apache
java1234_小锋5 小时前
Zookeeper脑裂是什么原因导致的?
分布式·zookeeper·debian
承悦赋5 小时前
初识Redis:解锁高性能缓存的魔法钥匙
数据库·spring boot·redis·分布式·缓存·中间件
wanhengidc5 小时前
云计算和云手机之间的关系
运维·网络·游戏·智能手机·架构·云计算
Jabes.yang5 小时前
互联网大厂Java面试:从Spring Boot到微服务的实战考验
大数据·redis·微服务·spring security·java面试·sring boot·sring cloud