kafka测试方案

本文详述了kafka接入数据中台的验证预案,包括性能验证(发送量、消费量、broker容量等)、功能验证(生产、消费、管理功能等)和集群验证,以及实施预案,涉及架构设计、容量规划、数据采集等方面,确保kafka在数据中台的高效稳定运行。
摘要由CSDN通过智能技术生成

1引言

数据中台因业务需要将要引入开源框架kafka。

本文主要内容为kafka接入数据中台的技术验证预案和实施建设预案。

2验证预案

2.1性能验证

验证kafka的高吞吐率,主要验证producer和consumer的发送和消费吞吐率。

使用kafka manager 监控。

发送量测试

测试环境设定:broker集群(3节点),topic(1个),partition(3节点*2),replication(3)。

1、在borker不变的情况下,producer数量变化,测试多个producer发送消息的吞吐性能。

2、在borker不变的情况下,producer数量不变,消息数量变化,测试多个producer发送消息的吞吐性能。

3、在borker不变的情况下,producer数量不变,消息大小变化,测试多个producer发送消息的吞吐性能。

4、在borker不变的情况下,producer数量不变,partition数量变化,测试多个producer发送消息的吞吐性能。

5、在borker不变的情况下,producer数量不变,replication变化,测试多个producer发送消息的吞吐性能。

6、同时挂载producer和consumer,测试发送消息和消费消息的吞吐性能

7、在borker数量变化的情况下,测试发送消息和消费消息的吞吐性能。

结论预设:随着producer数量的增加,每秒总的消息量会增加。随着消息变大,每秒总的消息量会增加。partition越多,在某阈值范围内,吞吐率提高。replication越大,吞吐率下降。

消费量测试

测试环境设定:broker集群(3节点),topic(1个),partition(3节点*2),replication(3)      。

1、在borker不变的情况下,consumer数量变化,测试多个consumer接收消息的消费性能。

2、在borker不变的情况下,consumer数量不变,消息数量变化,测试多个consumer接收消息的吞吐性能。

3、在borker不变的情况下,consumer数量不变,消息大小变化,测试多个consumer接收消息的吞吐性能。

4、在borker不变的情况下,consumer数量不变,partition数量变化,测试多个consumer接收消息的吞吐性能。

5、在borker不变的情况下,consumer数量不变,replication变化,测试多个consumer接收消息的吞吐性能。

6、同时挂载producer和consumer,测试发送消息和消费消息的吞吐性能

7、在borker数量变化的情况下,测试发送消息和消费消息的吞吐性能。

结论预设:随着consumer数量的增加,消息消费的速度会越快。

broker容量测试

关闭consumer,通过producer发送海量数据到broker,测试broker的容量承载能力。

异步消息测试

配置消息异步发送,按照吞吐率测试方案测试producer和consumer的吞吐性能。

配置消息异步发送,查看数据丢失情况。

同步消息测试

配置消息同步发送,按照吞吐率测试方案测试producer和consumer的吞吐性能。

配置消息同步发送,查看数据丢失情况。

消息重发测试

测试broker进程异常状态下,producer和consumer的消息重发机制。

offset相关测试

修改offset后,会产生消息重复、丢失、乱序等情况,具体进行测试。

partition方式测试

设定partition分配的方式,随机或者hash,来测试具体情况

压缩比测试

分别设定不同的压缩算法,GZIP, Snappy, LZ4,再次进行上述吞吐率的测试。

zookeeper下线测试

zookeeper节点下线后,测试kafka集群的稳定情况。

网络带宽占用测试

容错测试

满负荷测试

加大producer和consumer的数量及数据量,直至主机资源消耗的70%以上,观察运行时间长度。

崩溃测试

加大producer和consumer的数量及数据量,直至主机资源耗尽。

断网断电测试

断网断电测试broker的数据丢失情况。

2.2功能验证

验证kafka提供的各种功能。

生产消息

编写producer发送消息。

消费消息

编写consumer消费消息。

主题管理

测试topic的创建、更新、删除等管理功能。

分区管理

测试partition的添加、删除等管理功能。

测试topic与多个partition关联后的管理功能。

日志管理

测试集群报错后,kafka提供的日志报错功能。

集群监控

测试kafka manager对集群metrics的监控功能,集群状态、topic、partition、replica、consumer group、log等。

2.3集群验证

对kafka集群进行架构验证

新增节点

新增节点后,kafka集群的运行情况。

删除节点

删除节点后,kafka集群的运行情况。

zookeeper下线

删除zookeeper节点后,kafka集群的运行情况。

断网测试

断网后,kafka集群的运行情况。

断网再接入网络后,kafka集群的运行情况。

断电测试

断电重启后,kafka集群的运行情况。

3实施预案

kafka接入数据中台,需要从如下方面准备:

架构设计

 

如上图所示,kafka按分布式集群方案部署后,需要在应用系统端定制producer来采集数据,在数据中台端定制consumer来往中台写入数据。

容量规划

从数据流转、存储的角度,搞清楚数据采集端的数据容量、broker集群的数据容量、数据消费端的数据容量。

首先需要搞清楚如下情况:

有哪些数据要接入

数据所在物理位置

数据存储的应用软件

每个producer的部署位置

每个producer的部署环境

每个producer采集数据的安全权限

每个producer采集数据的频度

每个producer的资源消耗(主机、带宽)

每个consumer group个数

每个consumer group中consumer的个数

每个consumer连接中台的技术接口

每个consumer访问中台的权限

每个consumer的部署位置

每个consumer对中台资源的消耗

其他

总之要汇总得出如下结论:

producer的数量

producer的位置

producer的日数据总量

producer的并发量

producer的并发数据量

producer资源配置(cpu、内存、硬盘、带宽)

borker集群个数

broker集群资源配置(cpu、内存、硬盘、带宽)

broker日数据量峰值

broker日存储最大数据量

topic数量

topic配置

topic关联partition的数量

replica配置量

consumer group的数量

每个consumer group中consumer的数量

每个consumer对接中台的接口

每个consumer对接中台权限

consumer日消费数据总量

consumer消费数据的并发量

consumer消费数据的并发数据量

consumer资源配置(cpu、内存、硬盘、带宽)

其他

数据采集

在应用系统端,定制并部署producer,用来采集数据。

producer对接应用系统。

producer采集应用数据到broker。

producer在应用系统测部署运维。

broker部署

依据容量规划,规划broker集群的部署位置、资源配置、主机规划、带宽要求等。

写入中台

在数据中台端,定制并部署consumer,往中台写入数据。

consumer对接数据中台。

consumer消费数据到数据中台。

consumer在数据中台测部署运维。

技术培训

需要协调应用系统开发商和数据中台开发商,共同分析需求,定制producer和consumer。

对接应用系统开发商,编写producer。

对接数据中台开发商,编写consumer。

日常运维

运维团队通过kafka manager运维kafka集群,改造manager,能够自动预警、报警。

运维团队直接运维producer。

运维团队直接运维consumer。

附:产品分析

概念分析

产品定义

Kafka是一种高吞吐量、分布式、基于发布/订阅的消息系统,最初由LinkedIn公司开发,使用Scala 语言编写。目前是Apache组织的开源项目。

kafka主要概念组件如下:

1、 broker:Kafka服务器,负责消息存储和转发。

2、 topic:消息主题,Kafka按照topic来分类消息。

3、 partition:topic的分区,一个topic可以包含多个partition,topic消息保存在各个partition 上。

4、 offset:消息在日志中的位置,可以理解是消息在partition 上的偏移量,也是代表该消息的唯一序号。

5、 Producer:消息生产者。

6、 Consumer:消息消费者。

7、 Consumer Group:消费者分组,每个Consumer 必须属于一个group。

8、 Zookeeper:保存着集群broker、topic、partition 等meta 数据;另外还负责broker 故障发现,partition leader 选举,负载均衡等功能。

工作机制

Kafka基于分布式高可用的borker提供强大的数据缓冲能力,producer对接数据源采集数据,并将数据发送到broker上,数据就在borker上缓存下来,直到consumer消费完数据为止。

Kafka基于分布式架构提供高容错功能,基于offset记录已经处理过的数据,消息写入topic有顺序,consumer记录自己的offset,topic数据存储在分区上,分区有副本,分布在不同节点上。

Kafka使用producer写入数据时,启用批次写入,这样可以避免在网络上频繁传输单个消息带来的延迟和带宽开销。假设网络带宽为10MB/S,一次性传输10MB的消息比传输1KB的消息10000万次

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值