压力测试
创建单分区单副本主题
kafka-topics.sh \
--create \
--replication-factor 1 \
--partitions 1 \
--zookeeper hadoop100:2181/kafka \
--topic t3
| 生产者参数 | 描述 | 备注 |
|---|---|---|
--topic | 生产到哪个主题 | |
--num-records | 生产多少条消息 | |
--throughput | 最大消息吞吐量限制,-1不限制 | messages/sec |
--record-size | 每条消息的大小 | bytes |
--print-metrics | 打印指标 | 默认不打印 |
--producer-props | 生产者相关配置,如服务器地址 | 优先级高于--producer.config |
--producer.config | 生产者配置文件路径 |
kafka-producer-perf-test.sh \
--throughput -1 \
--print-metrics \
--num-records 1000000 \
--record-size 1024 \
--producer-props bootstrap.servers=hadoop100:9092 \
--topic t3
| 消费者参数 | 描述 | 默认值 | 备注 |
|---|---|---|---|
--bootstrap-server | 服务器连接地址 | 必要参数 | |
--consumer.config | 消费者配置文件路径 | ||
--date-format | 时间字段的格式 | yyyy-MM-dd HH:mm:ss:SSS | |
--fetch-size | 单次请求 拿取的数据大小 | 1048576 | |
--from-latest | 从最尾的消息开始消费 | ||
--group | 消费者组 | perf-consumer-89916 | |
--hide-header | 不打印状态头 | ||
--messages | 消费的消息数量 | 必要参数 | |
--print-metrics | 打印指标 | ||
--socket-buffer-size | The size of the tcp RECV size | 2097152 | |
--timeout | 返回记录期间允许的最大时间 | 10000 | 单位:毫秒 |
--topic | 消费哪个主题 | 必要参数 |
kafka-consumer-perf-test.sh \
--print-metrics \
--messages 1000000 \
--bootstrap-server hadoop100:9092 \
--topic t3
参数优化
主要参数优化
| 文件 or 命令 | 参数名 | 参数说明 | 参数值建议 | 说明 |
|---|---|---|---|---|
server.properties | log.retention.hours | 数据保留时间 | 72 | 建议3天 |
server.properties | default.replication.factor | 默认副本策略 | 2 | 建议>1 |
kafka-topics.sh | --replication-factor | 创建主题时副本策略 | 2 | 建议>1 |
kafka-server-start.sh | KAFKA_HEAP_OPTS | 内存 | -Xms5G -Xmx5G | 建议不超过6G |
单条日志传输大小
- Kafka对于消息体的大小默认为单条最大值是1M;
但某些场景里一条消息大于1M,此时需要配置server.properties文件的如下参数
| 参数名 | 参数说明 |
|---|---|
replica.fetch.max.bytes | Broker可复制的消息的最大字节数 |
message.max.bytes | Kafka会接收单个消息size的最大限制 要求: message.max.bytes≤replica.fetch.max.bytes |
过期数据清理
| 两种策略 | 参数 |
|---|---|
| 删除策略 | log.cleanup.policy = delete |
| 压缩策略 | log.cleanup.policy = compact |
异常处理
Kafka挂了咋办?
- 通常挂掉的原因:OOM
-
挂掉以后有什么不良后果?
生产数据丢失:当ack=1且Leader收消息后还没来得及同步就挂了时,数据会丢失
当ack=-1,并且消费者没有开启事务,并且消费者操作非幂等 时,数据会重复 -
处理方式
1、重启Kafka
2、查看日志错误信息
3、优化配置(例如内存)以减少挂掉的概率
4、处理丢失或重复的数据
数据积压
-
原因:消费者太慢或挂掉
-
影响:积压3天后没被消费,数据丢失
-
解决方案:
1、加主题的分区数,并且同时增加消费组的消费者数,使得 消 费 者 数 = 分 区 数 消费者数=分区数 消费者数=分区数
2、优化消费者,如:增加每批次拉取的数量
主题和分区的设计
-
Kafka数据在分区内有序,在主题中不一定有序
-
如何划分主题?
按日志类型
MySQL导过来的话,一个表一个分区 -
多少个分区?
要求有序则单分区(慢)
按表中不影响排序的字段(如:地区)… -
Kafka分区数计算
1、创建单分区主题
2、测试该主题的生产者吞吐量和消费者吞吐量(使用内置脚本)
3、 分 区 数 = 吞 吐 量 预 期 / m i n ( 吞 吐 量 生 产 者 , 吞 吐 量 消 费 者 ) 分区数=吞吐量_{预期}/min(吞吐量_{生产者},吞吐量_{消费者}) 分区数=吞吐量预期/min(吞吐量生产者,吞吐量消费者)
消费者策略
- 消 费 者 组 的 消 费 者 数 = 主 题 的 分 区 数 消费者组的消费者数=主题的分区数 消费者组的消费者数=主题的分区数
- 按照时间消费数据
- 自动提交消费者偏移量(速度快但故障后可能会丢数据)
- 手动提交消费者偏移量(降低数据风险但增加代码复杂度)
附录
| en | 🔉 | cn |
|---|---|---|
| latency | ˈleɪtənsi | n. 潜伏;潜在因素;延迟 |
| fetch | fetʃ | vt. 取来;vi. 拿;取物;n. 取得;诡计 |
生产者压测结果
| records sent | records/sec | MB/sec | avg latency | max latency |
|---|---|---|---|---|
| 125206 | 25041.2 | 24.45 | 1002.4 ms | 1165.0 ms |
| 137040 | 27397.0 | 26.75 | 1127.2 ms | 1402.0 ms |
| 165870 | 33174.0 | 32.40 | 938.1 ms | 1049.0 ms |
| 166440 | 33288.0 | 32.51 | 924.9 ms | 1004.0 ms |
| 169725 | 33945.0 | 33.15 | 900.9 ms | 958.0 ms |
| 160980 | 32196.0 | 31.44 | 952.6 ms | 1078.0 ms |
| 1000000 | 30971.258672 | 30.25 | 965.92 ms | 1402.00 ms 932 ms 50th 1161 ms 95th 1264 ms 99th 1395 ms 99.9th |
消费者压测结果
| data.consumed.in.MB | MB.sec | data.consumed.in.nMsg | nMsg.sec | rebalance.time.ms | fetch.time.ms | fetch.MB.sec | fetch.nMsg.sec |
|---|---|---|---|---|---|---|---|
| 976.5625 | 119.2821 | 1000000 | 122144.8638 | 1631504172888 | -1631504164701 | -0.0000 | -0.0006 |
吞
吐
量
预
期
=
12
M
/
秒
吞吐量_{预期} = 12M/秒
吞吐量预期=12M/秒
分
区
数
=
吞
吐
量
预
期
/
m
i
n
(
吞
吐
量
生
产
者
,
吞
吐
量
消
费
者
)
=
12
/
m
i
n
(
30
,
119
)
=
12
/
30
分区数=吞吐量_{预期}/min(吞吐量_{生产者},吞吐量_{消费者})=12/min(30,119)=12/30
分区数=吞吐量预期/min(吞吐量生产者,吞吐量消费者)=12/min(30,119)=12/30
分区数设置为1
2192



被折叠的 条评论
为什么被折叠?



