kafka生产经验

最新推荐文章于 2024-07-24 14:50:21 发布
最新推荐文章于 2024-07-24 14:50:21 发布
阅读量1.3k 收藏 37
点赞数 28
文章标签： kafka 分布式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_18628605/article/details/135713543
版权

生产经验

生产者提高吞吐量

  1. linger.ms：表示一个batch还未满时，时隔多久开始发送。默认是0ms，即缓冲区中一有数据就开始向kafka集群开始发送，此时批次大小的数据没有意义。一般修改linger.ms=5~100ms，给缓冲队列一些时间让他能够向其中存放数据，能够按照batch进行数据发送。也不要设的太大，避免数据量少的时候长时间不发送。
  2. batch.size：批次大小，一个batch中存放多少数据。
  3. compression.type：压缩方式snappy，压缩数据能够减小数据大小，提高数据吞吐效率。可以选择的压缩方式:
    • snappy
    • gzip
    • lz4
    • zstd
  4. RecordAccumulator：缓冲区大小，默认32Mb，可以修改为64Mb

数据有序

生产者处按照有序的顺序产生数据，写入不同的分区中，消费者在读取数据的时候，因为需要从不同的分区中读取数据，在同一分区内的数据是保持有序的，但是在不同分区之间的数据是无序的。
在单分区中的有序也是有条件的。
如果需要多分区中的数据依旧保持有序，那么需要在消费者端创建多个窗口，等待数据全部到达消费者端后，在消费者端进行统一排序，反而降低了效率。

数据乱序

  1. 在生产者端，默认每个broker最多缓存5个请求，就是最多可以同时等待五个请求收到回应
  2. 如果12的请求发送成功了，3的消息发送请求被阻塞了，4的消息发送成功了。此时会导致broker分区中数据的乱序（应该1234，但实际上1243了）。为解决这个问题
    1. 1.x版本之前保证单分区有序：
      • max.in.flight.requests.per.connection=1表示缓存队列中最多只能缓存一个请求，那么分区内一定是有序的，因为失败的请求就会被阻塞，直到成功为止。此时甚至不需要开启幂等性
    2. 1.x版本之后：
      • 如果没有开启幂等性：max.in.flight.requests.per.connection=1
      • 如果开启了幂等性：max.in.flight.requests.per.connection需要设置小于等于5
      • 原因：开启幂等性之后，kafka的服务端会缓存producer发来最近的5个请求的元数据。无论请求完成的时间顺序，服务端是根据这5个元数据内容对数据进行排序，必定能够保证这5个request的数据有序。
      • 元数据中包含有sequence number，这个值是单调递增的，因此可以根据该值对数据进行排序。如果sequence number较大的数据先到达了，那么就会等待所有数据都到齐了之后，在服务器端对所有数据进行排序之后再落盘。

节点的服役

创建了一个新节点，修改完相关内容后，该节点并没有直接加入到kafka集群中

负载均衡操作

  1. 创建一个需要均衡的主题，通过创建一个json文件topics_to_mv.json
{
    "topics":[
        {"topic": "first"},
        {"topic": "second"}
    ],
    "version":1
}
  1. 生成一个负载均衡计划
    bin/kafka-reassign-parititons.sh --bootstrap-server node1:9092 --topics-to-move-json-file topics_to_move.json --broker-list "1,2,3,4" --generate
    • --topics-to-move-json-file 指定按照哪个文件，对哪个主题进行负载均衡操作
    • --broker-list 指定需要对那几台broker进行负载均衡
    • --generate 生成负载均衡计划
  2. 创建副本存储计划increase_replication_factor.json
    在这里插入图片描述

就是把之前生成的负载均衡计划给拿过来
4. 执行这个副本存储计划
bin/kafka-reassign-parititons.sh --bootstrap-server node1:9092 --reassignment-json-file increase_replication_factor.json --execute

  • --reassignment-json-file 副本存储计划地址
  • --execute 执行
  1. 验证副本存储计划,用于判断这个计划是否已经执行完毕了
    bin/kafka-reassign-parititons.sh --bootstrap-server node1:9092 --reassignment-json-file increase_replication_factor.json --verify
    • --verify 将之前的execute改成verify，验证对应的计划

节点的退役

和服役一个新节点基本一致，只需要在生成负载均衡计划的时候，将对应需要退役的节点的brokerid进行去除即可。
这样操作就能够将这个节点上原先的数据转移到其他节点上，让其他节点重新负载均衡其上面的数据.

手动调整分区副本存储

实际生产的环境中，可能存在一些机器性能高，而一些机器性能低的情况。kafka默认的分区情况是不考虑机器资源的负载均衡的，其只考虑机器数量上的负载均衡问题。因此需要根据实际手动调整分区数量。

现在假设希望将所有的数据存储在node1和node2上

  1. 创建副本存储计划increase-replication-factor.json
{
   "version":1,
   "partitions":[
      {
         "topic":"test",
         "partition":0,
         "replicas":[0,1]
      },
      {
         "topic":"test",
         "partition":1,
         "replicas":[0,1]
      },
      {
         "topic":"test",
         "partition":2,
         "replicas":[1,0]
      },
   ]
}

就是让原先在2上的数据重新负载均衡到0，1上。
2. 执行改副本存储计划bin/kafka-reassign-partitions.sh --bootstrap-servers node1:9092 --reassignment-json-file increase-replication-factor.json --execute
和之前的节点退役重负载均衡问题类似

leader partition的负载均衡

  • 一般情况下，kafka会自动把leader partition均匀分布到各个机器上，确保每台机器的读写吞吐量均匀。
  • 如果某些broker宕机了，会导致leader partition过度集中在少数几台broker上，导致这几台机器的压力过高。
  • 宕机的broker重启后会自动成为follower，读写请求较低，造成集群的负载不均衡。
  • 就是一开始大家都会有一些不同分区的leader，但是有些broker宕机了，这些leader就会被发放到其他的broker上，有些broker此时可能就会有多个leader副本，导致压力的增大
  • 为了解决这个问题，kafka有一个参数auto.leader.rebalance.enable，开启后能够自动进行leader partition的均衡。该参数默认开启。
  • 在生产环境中，该值一般不开启。因为很多时候虽然计算了不平衡率是不平衡的，但是实际上其分配的比例还是满足我们需要的，而自平衡需要浪费资源，为避免资源浪费可以关闭该功能。
  • leader.imbalance.per.broker.percentage，每个broker允许的不平衡leader比例。如果每个broker上不平衡的leader都超过了这个值，就会由Controller来进行leader的再平衡。该值默认是10%。如果开启了自动平衡，推荐将不平衡比例调大，确保不会轻易的进行自平衡。
  • leader.imbalance.check.interval.seconds检查leader负载是否均衡的间隔时间，默认300s

不平衡比例计算

  • 按照正常情况，replicas中第一个副本所在的分区应该和leader是保持一致的，如果不同，说明发生过节点的宕机，它上面的leader被分配到其他节点上了。

  • 计算某个节点的不平衡比例
    在这里插入图片描述

  • 0号分区本来应该是partition2的leader，因为他在partition2的replicas中排第一个，但实际上不是，因此有一个不平衡数

  • 对于0号节点，AR总副本数为4，有一个不平衡数，因此1/4=25%>10%，0号节点不平衡

增加副本因子

某些主题可能在生产过程中重要等级发生了提升，需要对该主题增加副本数。同样是在json中制定号对应的重负载计划，然后按照计划进行执行。

消费者生产经验

分区分配

到底哪个consumer来消费哪个partition中的数据
kafka提供了4种主流的分区分配策略

  • Range
  • RoundRobin
  • Sticky
  • CooperativeSticky

通过修改配置参数partition.assignment.strategy 来修改对应的分区分配策略，默认策略为Range+CooperativeSticky
kakfa可以同时使用多个分区分配策略

  1. Range
    1. 针对同一个topic中的分区
    2. 对同一个topic中的分区按照序号进行排序，并对消费者按照字母顺序进行排序
    3. 通过partition / consumer 来决定每个消费者需要消费几个分区。如果这个结果除不尽，那么前面的消费者需要多消费几个分区
    4. 如果topic的数量非常多，假设有N个，每个都除不尽，那么第0个分区就要比其他分区多处理N个分区，会造成数据倾斜
  2. RoundRobin
    1. 针对所有的topic中的所有分区而言
    2. 通过轮询的分区策略，把所有的consumer和partition都列出来，然后按照hashcode进行排列，通过轮询的方法来分配partition到各个消费者。
  3. Sticky
    1. 针对所有的topic中的所有分区
    2. 首先会尽量均衡的放置分区到CG上，如果同一CG中的其他消费者出现问题，会尽量保持原有分配的分区不发生变换
    3. 执行新的一次分配之前，考虑上一次分配的结果，尽量减少调整分配，节省开销

数据积压

这个问题的关键就是在于如何提高consumer对应的吞吐量

  1. 如果是kafka的消费能力不足，那么可以考虑增加topic的分区数量，同时提高消费者组中的消费者数量，保证消费者数=分区数
  2. 如果是下游的数据处理的不及时，可以调高每批次拉取的数量。批次拉取的数据量过少的时候，会使得处理的数据小于生产的数据，造成数据的积压，确保拉取数据/处理速度>生产速度

kafka调优

场景： 100w日活，每人每天100条日志，每天日志总数1亿条

  • 1150条/秒钟
  • 每条日志 0.5k-2k，取1k
  • 1mb/s
  • 高峰期大约有20倍，23000/s
  • 20mb/s
  • 平均没什么太大意义，主要要看峰值的状态

硬件选择

  1. 服务器台数 = 2 * (生产者峰值速率 * 副本数 /100) + 1 = 2 * (20 m/s * 2 / 100) + 1 = 3 台
  2. 磁盘
    1. kafka 按照顺序读写，在顺序读写的方面，固态和机械差不多，可以选机械硬盘
    2. 1 亿 * 1k * 2(副本) * 3(天数) / 0.7 = 1 t
    3. 三台服务器总的磁盘大小需要>1t
  3. 内存
    1. kafka内存 = 堆内存 (kafka内部配置) + 页缓存 (服务器内存)
    2. 堆内存： 10-15g 就是修改kafka-server-start.sh 中的配置
    3. 页缓存 使用segment来存储(1g)，一般放25%。 页缓存=分区数 * 1g * 25% / 服务器台数
    4. 一台机器应该 10-15g + 1-2g
  4. CPU 选择
    1. num.io.threads=8 负责写磁盘的线程数，占总核数的50%
    2. num.replica.fetchers=1 副本拉取线程数 占总核数1/6
    3. num.network.threads=3 数据传输线程 占总核数1/3
    4. 还会有很多线程独立在运行中
    5. 一般建议32个cpu核
  5. 网络选择
    网络带宽 = 峰值吞吐量 一般选择千兆网卡

自动创建主题

auto.create.topics.enable 如果没有主题的时候就向其中发送消息，系统会自动创建一个主题，该主题是非预期的，增加了主题管理和维护上的难度，因此该值一般置为false

kafka 总体调优

吞吐量

  1. 增加生产者吞吐量
    1. buffer.memory
    2. batch.size
    3. linger.ms
    4. compression.type
  2. 增加分区数量
  3. 消费者端提高吞吐量
    1. fetch.max.bytes
    2. max.poll.records
  4. 增加下游消费者的处理能力

数据精准一次

  1. 生产者
    1. ack=-1
    2. 幂等性+事务
  2. broker端
    1. 分区副本数大于等于2
    2. ISR应答的最小副本数大于等于2
  3. 消费者
    1. 事务+手动offset
    2. 消费者的目的地必须支持事务

合理设置分区数

  1. 创建只有一个分区的topic
  2. 测试该topic的producer和consumer的吞吐量
  3. 分区数 = 总吞吐量 / min(producer吞吐量，consumer吞吐量)
  4. 虽然可以计算，但是分区数也不是越多越好，一般设置在3-10个，可以先进行压测，再灵活调整分区个数

单条日志大于1m

kafka单条日志的默认上限是1m，如果消息大小超过1m了，那么会导致kafka可能卡住

  1. message.max.bytes：默认1m，broker端接受每批次消息的最大值
  2. max.request.size 默认1m，生产者向broker发送请求每个消息的最大值
  3. replica.fetch.max.bytes默认1m，副本同步时每个批次消息的最大值
  4. fetch.max.bytes消费者端一次拉取的最大数据量，但是这个一个软上限 默认50m

服务器宕机

  1. 尝试重启
  2. 重启不行，增加内存、cpu、磁盘、网络等方法
  3. 如果将整个节点误删除，如果有多的副本，可以重新服役一个节点后再均衡

集群压测

kafka自带了压测的脚本

  • 生产者 kafka-producer-perf-test.sh
  • 消费者 kafka-consumer-perf-test.sh

生产者压测

bin/kafka-producer-perf-test.sh --topic test --record-size 1024 --num-records 100000 --throughput 10000 --producer-props bootstrap.servers=node1:9092 batch.size=16384 linger.ms=0

参数描述
topic主题
record-size单条信息的大小，单位为字节
num-records总共发送的信息条数
throughput每秒多少条消息，设为-1表示不设限，尽可能快的生产数据，可测出生产者最大吞吐量
producer-props配置生产者的一些参数

消费者压测

kafka-consumer-perf-test.sh --bootstrap-servers:node1:9092 -topic test --message 1000000 --consumer.config config/consumer.properties

参数描述
topic主题
message发送的消息条数
consumer.config对应的消费者配置，与生产者压测不同的是，这个需要写在一个properties文件中，通过读取文件的方式加载配置
光军233
关注
查询Kafka生产者是否连接到Kafka服务
weixin_44976692的博客
06-22 5万+
java领域优质创作者🌐。
kafka-perf_2.x.x-0.8.1.jar
07-15
昨天在公司时，本来想用kafka官方提供的工具做性能测试的。但事与愿违，当我执行官方提供的kafka测试脚本，却报错没有找到ProducerPerformance，后来浏览一些代码文件，才发现没有把perf性能测试程序打包到kafka_2.x.0-0.8.x.x.jar发行版本中。
【kafka】kafka-producer-perf-test.sh
weixin_43346403的博客
07-01 239
由此可见， kafka-producer-perf-test.sh 工具进行性能测试，只是无脑写入，没有任何规范。仅仅只是测试了，写入性能。3.生产者和消费者属性查看。4.kafka服务端参数。1.kafka性能测试。
压测实操--kafka-consumer压测方案
最新发布
07-24 528
使用kafka自带的kafka-consumer-perf-test.sh脚本对集群消费情况进行压测，根据业务情况设置要测试的messager条数。不同的变量因素，通过修改其中一个变量条件，固定其余变量值，获取对应的吞吐速率。整理不同条件下的指标结果，形成曲线就可以观察具体的消费趋势。
Kafka 验证部署（单机版）kafka-producer-perf-test.sh 吞吐量测试工具的基本使用
是个好男人的博客
05-12 6515
1.测试topic创建与删除 （1）创建一个测试topic，名为test-topic。创建3个分区，每个分区分配1个副本（因为是单机kafka,如果是集群的话可以分配多个副本），如果分配的副本数大于broker的数量时，会报错 bin/kafka-topics.sh --zookeeper localhost:2181 --create --topic test-topic --partitions 3 --replication-factor 1 （2）查看topic是否创建成功 .
kafka 生产消费性能测试
dinghua_xuexi的专栏
10-08 1823
生产数据压力测试 kafka-producer-perf-test.sh 脚本命令的参数为： --topic topic名称，比如test --num-records 总共需要发送的消息数，比如为1000000 --record-size 每个记录的字节数，比如1000 --throughput 每秒钟发送的最大记录数，比如20000 --producer-props bootstrap.servers=kafka-01:9092,kafka-02:9092,kafka-03:9092 发送端的配置信息，
Kafka自带性能测试脚本使用
wdmzjzclf的博客
09-24 886
拓扑结构 1）producer： 　　消息生产者，发布消息到 kafka 集群的终端或服务。 2）broker： 　　kafka 集群中包含的服务器。 3）topic： 　　每条发布到 kafka 集群的消息属于的类别，即 kafka 是面向 topic 的。 4）partition： 　　partition 是物理上的概念，每个 topic 包含一个或多个 partition。kafka 分配的单位是 partition。 5）consumer： 　　从 kafka 集群中消费消息的终端或服..
Kafka
qq_24099547的博客
03-19 2872
目 前 企 业 中 比 较 常 见 的 消 息 队 列 产 品 主 要 有Kafka(在大数据场景主要采用 Kafka 作为消息队列。
kafka 经验
qq_34897849的博客
10-22 469
1、数据丢失和重复 kafka ack 设置为0 不等leader落盘直接确认回复 leader挂了 数据丢失 设置为1 时 leader落盘后不等所有副本全部落盘 确认回复 leader 挂了 选举新leader 无此数据 数据丢失 ACK设置为-1 leader和副本都落盘后确认回复 如果在落盘完成之后 leader回...
kafka kafka kafka kafka
05-05
提供的资料.zip可能包含Kafka的基本概念、架构、配置等方面的文档，笔记.zip可能包含了学习和使用Kafka的经验总结，而代码.zip可能包含了一些示例代码或者实际项目中使用Kafka的代码片段。这些资源可以帮助你深入...
使用Java编写Kafka生产者和消费者示例
热门推荐
weixin_44976692的博客
05-09 2万+
本文介绍了如何使用Java编写Kafka的生产者和消费者示例。通过这些示例代码，我们可以轻松地在Java应用中集成Kafka，实现消息的生产和消费。Kafka具有高性能、高可靠性的特点，适用于各种场景的消息处理需求。
apache kafka性能测试命令使用和构建kafka-perf
李志涛的专栏
07-06 1万+
Producer Setupbin/kafka-topics.sh --zookeeper esv4-hcl197.grid.linkedin.com:2181 --create --topic test-rep-one --partitions 6 --replication-factor 1bin/kafka-topics.sh --zookeeper esv4-hcl197.grid.lin
Kafka Producer通过参数调优提高数据发送速度
Daphnis的博客
04-22 4332
1. 前言 最近项目现场发生了 日志文件积压的情况，日志文件的大概处理流程是：读取日志文件->进行结构化->发送到 kafka 以一个 7.57M的日志文件为例（约58400条日志信息），程序需要 16.8s才能将其处理完，也就是说平均每秒只能处理约 3500条数据，经过验证，其中瓶颈在数据发送到 Kafka这一步。这个根据经验，明显肯定是没有达到 Kafka的瓶颈的，应该是自己 producer程序有问题，于是去 Kafka官网一查： Single producer thread, 3x a
Kafka 性能测试脚本详解
六开箱
03-25 1007
Apache Kafka 官方提供了两个客户端性能测试脚本，它们的存放位置如下： - 生产者性能测试脚本：$KAFKA_HOME/bin/kafka-producer-perf-test.sh - 消费者性能测试脚本：$KAFKA_HOME/bin/kafka-consumer-perf-test.sh 支持测试的性能指标包括：吞吐量（throughput）、最大时延（max-latency）、平均时延（avg-latency）等。
kafka 脚本发送_Kafka自带的性能测试脚本
weixin_39872334的博客
01-13 311
12月 23, 2016 |Nix.Huang压测写入消息./kafka-producer-perf-test.sh --topic test_perf --num-records 1000000 --record-size 1000 --throughput 20000 --producer-props bootstrap.servers=localhost:909288126 records ...
kafka基准测试
DF_XIAO的专栏
01-28 2312
1、测试环境 该benchmark用到了六台机器，机器配置如下 l  IntelXeon 2.5 GHz processor with six cores l  Six7200 RPM SATA drives l  32GB ofRAM l  1GbEthernet 这6台机器其中3台用来搭建Kafka broker集群，另外3台用来安装Zookeeper及生成测试数据。6个drive
【kafka性能测试脚本详解、性能测试、性能分析与性能调优】
qq_45442178的博客
06-12 2537
官方在kafka高版本发行时，修改了这个默认值，暂时理解为官网的推荐设置，但对于实时性较高的业务，比如实时统计用户访问量的分析，一般会启用这个配置，即设置为true，但对于可靠性较高的业务，比如银行的业务，宁可花费几分钟或几个小时的延时后再处理像信用卡支付的业务，也不会冒险处理错误的消息。因此，按真实的业务场景来设置即为合理。使用实时性较高的系统，也不建议采用该模式。，默认值为5000ms，即5秒提交一次，可以通过该参数来设置提交的频度，一般来说，提交频度越高，越会带来更高的系统开销，可靠性也随之提高。
Kafka集群吞吐量测试（生产者和消费者）
IT之一小佬的博客
10-19 1454
Kafka集群吞吐量测试（生产者和消费者）
Kafka性能测试之produce
跋跋寒的博客
08-13 9418
在kafka的bin目录下，有两个脚本kafka-producer-perf-test.sh 和kafka-consumer-perf-test.sh，这两个脚本的作用是用来测试生产者和消费者的。 [root@hostname bin]# ./kafka-producer-perf-test.sh --help usage: producer-performance [-h] --topic ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值