Kafka集群生产/消费的负载均衡(Rebalance)测试

最新推荐文章于 2024-07-12 10:30:01 发布
最新推荐文章于 2024-07-12 10:30:01 发布
阅读量2.2w 收藏 14
点赞数
分类专栏： Kafka 文章标签： Kafka librdkafka 负载均衡 rebalance
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/cjf_wei/article/details/57121845
版权

基于Kafka客户端的高级API，配合zookeeper的使用，可以有效的实现Kafka集群的Rebalance，提高生产环境下的健壮性。本文使用librdkafka(https://github.com/edenhill/librdkafka) 提供的高级API来实现生产/消费，作为测试的基础。

生产者的负载均衡
对于同一个Topic的不同Partition，Kafka会尽力将这些Partition分布到不同的Broker服务器上，这种均衡策略实际上是基于Zookeeper实现的。在一个Broker启动时，会首先完成Broker的注册过程，并注册一些诸如“有哪些可订阅的Topic”之类的元数据信息。生产者启动后也要到zookeeper下注册，创建一个临时节点来监听Broker服务器列表的变化。由于在Zookeeper下Broker创建的也是临时节点，当Brokers发生变化时，生成者可以得到相关的通知，从改变自己的Broker list。其他的诸如Topic的变化以及Broker和Topic的关系变化，也是通过Zookeeper的这种Watcher监听实现的。
在生产中，必须指定topic；但是对于partition,有两种指定方式：

  1. 明确指定partition(0-N)，则数据被发送到指定partition
  2. 设置为RD_KAFKA_PARTITION_UA，则kafka会回调partitioner进行均衡选取，partitioner方法需要自己实现。可以轮询或者传入key进行hash。未实现则采用默认的随机方法rd_kafka_msg_partitioner_random随机选择。

消费者的负载均衡
Kafka具有消费分组的概念，某个Topic的某个partition只能由一个Consumer group中的一个Consmer消费。但如果两个Consmer不在同一个Consumer group，那么他们是可以同时消费某Topic的同一个partition的。
对于某些低级别的API，Consumer消费时必须制定topic和partition，这显然不是一种很好的均衡策略。基于高级别的API，Consumer消费时只需制定topic，借助zookeeper可以根据partition的数量和consumer的数量做到均衡的动态配置。
消费者在启动时会到zookeeper下以自己的conusmer-id创建临时节点/consumer/[group-id]/ids/[conusmer-id]，并对/consumer/[group-id]/ids注册监听事件，当消费者发生变化时，同一group的其余消费者会得到通知。当然，消费者还要监听broker列表的变化。librdkafka通常会将partition进行排序后，根据消费者列表，进行轮流的分配。消费者负载均衡中涉及的更重要的一点还有如何动态的维护partition的offset，因为消费者可能是变化的，而offset需要由comsumer来维护，librdkafka是借助zookeeper和消费者队列实现的，具体可以查看librdkafka的实现源码。(ps: Kafka已推荐将consumer的位移信息保存在Kafka内部的topic中，即__consumer_offsets(/brokers/topics/__consumer_offsets)，并且默认提供了kafka_consumer_groups.sh脚本供用户查看consumer信息(sh kafka-consumer-groups.sh –bootstrap-server * –describe –group *)。在当前版本中，offset存储方式要么存储在本地文件中，要么存储在broker端, 具体的存储方式取决”offset.store.method”的配置，默认是存储在broker端)

Rebalance测试
下面基于librdKafka实现的C/C++客户端（0.9版本及以上），
测试Kafka集群的负载均衡。
测试环境及方法：

  • 三个broker通过zookeeper组成的集群；
  • 每个Topic默认三个分区，每个分区默认只有一个副本；
  • 通过增减生产者、消费者、broker来观察生产/消费的变化

1.配置kafka集群
由于条件有限，在同一个机器上启动三个broker来模拟kafka集群，三个broker使用另外安装的同一个zookeeper服务（实际集群中，每个broker通常在不同的机器上，也会使用不同host的zookeeper）
zookeeper的安装和启动并不复杂，在此略过。

cd /home/kafka/config
//准备三份用于启动kafka服务的配置
cp server.properties server-0.properties
cp server.properties server-1.properties
cp server.properties server-2.properties
三份配置中都要修改以下
broker.id=0(三个配置中分别修改为0,1,2)
port=9092(三个配置中分别修改为9092,9093,9094)
log.dirs=/tmp/kafka-logs-0(三个配置中分别修改为/tmp/kafka-logs-0,/tmp/kafka-logs-1,/tmp/kafka-logs-2)
num.partitions=3 (都设置为3，即每个topic默认三个partition)

2.测试
生产消费的负载均衡
启动三个broker：修改完配置后，开启三个shell窗口，分别启动三个broker
kafka/bin/kafka-server-start.sh server-X.properties
启动日志

...
[2017-02-19 20:38:39,766] INFO Kafka version : 0.10.1.1 (org.apache.kafka.common.utils.AppInfoParser)
[2017-02-19 20:38:39,766] INFO Kafka commitId : f10ef2720b03b247 (org.apache.kafka.common.utils.AppInfoParser)
[2017-02-19 20:38:39,775] INFO [Kafka Server 0], started (kafka.server.KafkaServer)

...
[2017-02-19 20:39:12,628] INFO Kafka version : 0.10.1.1 (org.apache.kafka.common.utils.AppInfoParser)
[2017-02-19 20:39:12,629] INFO Kafka commitId : f10ef2720b03b247 (org.apache.kafka.common.utils.AppInfoParser)
[2017-02-19 20:39:12,632] INFO [Kafka Server 1], started (kafka.server.KafkaServer)

...
[2017-02-19 20:42:18,809] INFO Kafka version : 0.10.1.1 (org.apache.kafka.common.utils.AppInfoParser)
[2017-02-19 20:42:18,809] INFO Kafka commitId : f10ef2720b03b247 (org.apache.kafka.common.utils.AppInfoParser)
[2017-02-19 20:42:18,812] INFO [Kafka Server 2], started (kafka.server.KafkaServer)

启动两个producer，创建名为xyz的topic，根据配置，该topic默认有3个partition:

[root@localhost producer]# ./producer 
Current RdKafka-ver:0.9.4-pre1
% Created producer rdkafka#producer-1
kafka的broker的日志变化分别是
//broker-0，名为xyz的topic的partition-2被分别到broker-0
[2017-02-19 20:45:17,268] INFO Partition [xyz,2] on broker 0: No checkpointed highwatermark is found for partition [xyz,2] (kafka.cluster.Partition)
//broker-1，名为xyz的topic的partition-0被分别到broker-1
[2017-02-19 20:45:17,325] INFO Partition [xyz,0] on broker 1: No checkpointed highwatermark is found for partition [xyz,0] (kafka.cluster.Partition)
broker-2，名为xyz的topic的partition-1被分别到broker-2
[2017-02-19 20:45:17,001] INFO Partition [xyz,1] on broker 2: No checkpointed highwatermark is found for partition [xyz,1] (kafka.cluster.Partition)
在/tmp/kafka-logs-[*]的变化也可以印证这一点

依次启动三个consumer：

//启动1台时，该消费者负责消费所有的3个partition
[root@localhost consumer]# ./consumer 
Current RdKafka-ver:0.9.4-pre1
RebalanceCb: Local: Assign partitions: xyz[0], xyz[1], xyz[2],

//启动2台时，会触发消费者的负载均衡
//consumer-1
[root@localhost consumer]# ./consumer 
Current RdKafka-ver:0.9.4-pre1
RebalanceCb: Local: Assign partitions: xyz[0], xyz[1], xyz[2], 
RebalanceCb: Local: Revoke partitions: xyz[0], xyz[1], xyz[2], 
RebalanceCb: Local: Assign partitions: xyz[0], xyz[1],

//consumer-2
[root@localhost consumer]# ./consumer 
Current RdKafka-ver:0.9.4-pre1
RebalanceCb: Local: Assign partitions: xyz[2],

//启动3台时，会再次触发消费者的负载均衡
//consumer-1
[root@localhost consumer]# ./consumer 
Current RdKafka-ver:0.9.4-pre1
RebalanceCb: Local: Assign partitions: xyz[0], xyz[1], xyz[2], 
RebalanceCb: Local: Revoke partitions: xyz[0], xyz[1], xyz[2], 
RebalanceCb: Local: Assign partitions: xyz[0], xyz[1], 
RebalanceCb: Local: Revoke partitions: xyz[0], xyz[1], 
RebalanceCb: Local: Assign partitions: xyz[0],

//consumer-2
[root@localhost consumer]# ./consumer 
Current RdKafka-ver:0.9.4-pre1
RebalanceCb: Local: Assign partitions: xyz[2], 
RebalanceCb: Local: Revoke partitions: xyz[2], 
RebalanceCb: Local: Assign partitions: xyz[1],

//consumer-3
[root@localhost consumer]# ./consumer 
Current RdKafka-ver:0.9.4-pre1
RebalanceCb: Local: Assign partitions: xyz[2],

当依次关闭consumer时，同样会触发类似的rebalance，再次不一一演示
使用两个producer轮流向topic-xyz发送消息，三个消费者会大致消费相同的消息数目

broker的均衡
如果此时关掉一个broker，那么所以的消费者和生产者客户端都会收到如下的提示

2017-02-19 21:06:02.206: LOG-3-FAIL: [thrd:localhost:9094/bootstrap]: localhost:9094/bootstrap: Connect to ipv4#127.0.0.1:9094 failed: Connection refused
2017-02-19 21:06:02.206: ERROR (Local: Broker transport failure): localhost:9094/bootstrap: Connect to ipv4#127.0.0.1:9094 failed: Connection refused
在此之后，producer发送的消息将不会被发送host为localhost:9094的broker；如果该broker又恢复了，那么producer和consumer都会在此连接上该服务，因为他们都听过zookeeper监听着broker的变化

PS:
a.在本文的情况下（一个topic只有三个partition），如果启动4个consumer了？
由于只有3个partition，那么最后会有一个consumer无法消费

b.Rebalance后的消费者的从哪儿开始消费了？
offset由客户端和zookeeper通过consumer队列维护全局的变化

  1. 倪超.从Paxos到Zookeeper分布式一致性原理与实践.电子工业出版社,2015.
  2. librdkafka问题总结.http://blog.csdn.net/lybingo/article/details/52808192?locationNum=1&fps=1
cjf_wei
关注
专栏目录
Kafka 设计之生产者与消费者
流华追梦的专栏
03-07 1092
接上一篇。本文将介绍 Kafka 设计中的生产者与消费者，通过对官方文档的阅读，来加深对 Kafka 生产者和消费者设计的理解。
Kafka 集群如何处理生产者和消费者处理消息速率差异问题?
将臣三代的博客
06-24 566
Kafka 通过多种机制有效处理生产者和消费者处理速率的差异问题，确保系统的高效和稳定运行。消息缓冲机制：在生产者和 Broker 端使用缓冲区来缓解速率差异。消费者的拉取模型：允许消费者根据自身处理能力拉取消息，避免过载。消费者组和负载均衡：通过分区分配和再平衡提高消费能力。消息积压处理：调整消息保留策略和扩展消费者组来处理积压。动态调整机制：通过动态调整生产者和消费者的参数，适应不同的处理速率。消费者健康监控和自动扩展：监控消费者状态，自动扩展实例提高处理能力。
flink消费kafka管理offset
longlovefilm的博客
11-25 2594
通过自定义kafkaconsumer的反序列方式是可以拿到kafka message的所有信息的，包括topic partition offset等。 自行设置偏移量保存位置 这里采用了zookeeper作为保存的地址，就是实时更新偏移量属性。再job挂掉后重新拉取偏移量保存下来 就能一次消费啦，但真正做到一次消费必须和业务场景结合来做，比如事务。 废话不多说啦，我本地实现了一个例子 <dependency> <groupId&g..
Kafka与zookeeper集群保证数据可靠、有序、配置负载均衡
chaojiyingxiong的博客
03-17 3092
kafka与zookeeper集群、消息可靠性、有序性，启动关闭sh脚本、zookeeper存kafka那些信息
Kafka Rebalance详解
最新发布
07-12 472
作者：耀灵。
Kafka的rebalance机制
黑曼巴
10-23 1064
这是针对Kafka的消费者的机制
【项目实战】Kafka 的 Leader 选举和负载均衡
激流丶的博客
07-20 2780
Kafka的Leader选举和负载均衡是保证高可用性、故障恢复、负载均衡和性能优化的重要机制。它们能够确保Kafka集群的稳定运行和高效处理大量数据的能力
Kafka负载均衡策略
鸭梨的博客
02-05 2756
分区器 分区器是生产者层面的负载均衡。Kafka 生产者生产消息时，根据分区器将消息投递到指定的分区中，所以 Kafka 的负载均衡很大程度上依赖于分区器。 Kafka 默认的分区器是 Kafka 提供的 DefaultPartitioner。它的分区策略是根据 Key 值进行分区分配的： 如果 key 不为 null：对 Key 值进行 Hash 计算，从所有分区中根据 Key 的 Hash 值计算出一个分区号；拥有相同 Key 值的消息被写入同一个分区； 如果 key 为 null：消息将以轮询的方式
Kafka分区可靠性及负载均衡如何实现
初心江湖路的博客
11-04 1476
1、当brocker出现异常失败状况的时候Kafka集群会有什么动作？ 将日志同步到磁盘，以避免重启时进行日志恢复，日志恢复很耗时。 只要server不是因为被kill，日志同步便会自动进行。 进行leadership迁移，将该server作为leader的分区迁移到其他的副本上，然后其它副本便作为新的leader提供服务。 需要配置 controlled.shutdown.enable=...
Kafka学习--- 消费者分区分配策略与再均衡Rebalance
qq_36697880的博客
10-24 2349
一、消费者和消费者组 当生产者向 Topic 写入消息的速度超过了消费者（consumer）的处理速度，导致大量的消息在 Kafka 中淤积，此时需要对消费者进行横向伸缩，用多个消费者从同一个主题读取消息，对消息进行分流。 Kafka 的消费者都属于消费者组（consumer group）。一个组中的 consumer 订阅同样的 topic，每个 consumer 接收 topic 一些分区（partition）中的消息。同一个分区不能被一个组中的多个 consumer 消费。 假设现在有一...
Kafka详解(包括kafka集群搭建)
热门推荐
wudidahuanggua的博客
09-29 6万+
对kafka细致的解析，从理论到集群搭建实战
phpkafkaconsumer是一个kafkaconsumer库支持group和rebalance
08-08
php-kafka-consumer 主要是对 php_rdkafka 的 consumer 的 API 进行一层封装，增加了原程序中所没有的与 zookeeper 交互的功能。
kafka中leader和follower、AR、ISR、OSR、Controller的选举、为什么不能通过ZK的方式来选举partition的leader？
qq_40585384的博客
12-29 2503
在Kafka中，每个topic都可以配置多个分区以及多个副本。每个分区都有一个leader以及0个或者多个follower，在创建topic时，Kafka会将每个分区的leader均匀地分配在每个broker上。我们正常使用kafka是感觉不到leader、follower的存在的。但其实，所有的读写操作都是由leader处理，而所有的follower都复制leader的日志数据文件，如果leader出现故障时，follower就会被选举为leader**。**
kafka的选举和负载均衡策略
much efforts, much luck
06-12 1218
kafka的选举和负载均衡策略 1、kafka Controller leader:主broker的选举 主broker的作用：Controller Broker的主要职责有很多，主要是一些管理行为，主要包括以下几个方面： 创建、删除主题，增加分区并分配leader分区 集群Broker管理（新增 Broker、Broker 主动关闭、Broker 故障) preferred leader选举 分区重分配 主broker的选举流程：Kafka的Leader选举是通过在zookeeper上创建/contr
kafka应用场景、集群容量规划和架构设计
jiedaodezhuti的博客
07-06 786
Kafka 基本概念 kafka是一种高吞吐量的分布式发布/订阅消息系统。 业务需求模型，即生产者生产（Produce）各种数据，消费者（Consume）消费（分析、处理）这些数据。这就需要在生产者与消费者之间，建立一个通信的桥梁，这个桥梁就是消息系统。 2.kafka术语 Broker：Kafka 集群包含一个或多个服务器，每个服务器被称为 Broker。 Topic：每条发布到 Kafka 集群的消息都有一个分类，这个类别被称为 Topic（主题）。 Producer：消息的生产者，负责发布消息到 K.
Kafka入门之consumer--rebalance流程
weixin_30593443的博客
07-18 268
重平衡(rebalance) 旧版本Kafka依托于Zk进行rebalance，新版本consumer使用了Kafka内置的一个全新的组协调协议。对于每个组而言，Kafka的某个broker会被选举为组协调者(coordinator)。 触发条件： 1.组成员发生变更。 2.组订阅topic数发生变更。比如使用基于正则表达式的订阅，当匹配正则表达式的新topic被创建时则会触发r...
（3.2）broker源码——kafka如何rebalance重平衡
weixin_43930865的博客
06-15 674
rebalance是重新进行负载均衡的过程。包括集群的rebalance，消费和生产者的rebalance 。broker的rebalance：每个broker上的分区leader个数尽量保持一致，从而保证生产或者消费时节点的cpu,io，磁盘等保持基本一致。默认每个broker上的leader差异超过10%此时会触发broker上的leader迁移。它本质上是一组协议，它规定了一个 consumer group 是如何达成一致来分配订阅 topic 的所有分区的。...............
Kafka集群Broker没起到负载均衡作用
yjh314的专栏
11-02 5193
目前Kafka集群部署了4个Broker节点，但在压测的过程中，推送消息到Kafka没有起到负载均衡，都只推送到一台Broker节点， 1、查看推送程序物理机连接kafka端口6667的TCP连接，确实只有一台 [root@~]# ss -anp |grep ':6667' |grep '11314' (Linux查看方式) tcp ESTAB 0
Flink对接kafka自行管理offsets
梧桐听夜雨
04-01 3125
Flink再接入kafka时候难免会遇到重复消费和少消费场景 网上很多还没有flink的偏移量管理的好文档 自行设置偏移量保存位置 这里采用了zookeeper作为保存的地址，就是实时更新偏移量属性。再job挂掉后重新拉取偏移量保存下来 就能一次消费啦，但真正做到一次消费必须和业务场景结合来做，比如事务。 废话不多说啦，我本地实现了一个小demo 先导入必要的pom <d...
kafka rebalance机制
09-05
### 回答1： Kafka使用Rebalance机制来确保消费者群组中的消费者消费相同数量的分区，并确保消费者在分区分配发生更改时能够正确地处理它们。 当消费者加入或离开群组时，Kafka会触发Rebalance过程。在Rebalance过程中，Kafka会重新分配分区以确保每个消费者都消费相同数量的分区。Rebalance的过程可以分为两个阶段： 1. Revoke阶段：在此阶段，Kafka会将消费者正在消费的所有分区的控制权从消费者手中收回。这样可以确保在Rebalance期间不会有任何数据丢失。 2. Assign阶段：在此阶段，Kafka会重新分配分区以确保每个消费者都消费相同数量的分区。Kafka会确保在分配分区时考虑消费者的偏移量，以确保不会重复消费数据。 总的来说，Kafka的Rebalance机制是一种非常强大和可靠的机制，可以确保消费者群组中的消费者消费相同数量的分区，并确保在分区分配发生更改时能够正确地处理它们。 ### 回答2： Kafka的rebalance机制是指在消费者组中添加或移除一个消费者时，Kafka如何重新分配分区给消费者。 当有新的消费者加入消费者组时，Kafka会根据分区的数量和消费者组的消费者数量来重新分配分区。Kafka首先计算出每个消费者应该处理的分区数量，然后将剩余的分区平均分配给所有的消费者。这样可以使得每个消费者处理大致相等的负载。 当有消费者离开消费者组时，Kafka会将该消费者所处理的分区重新分配给其他消费者。重新分配分区的策略有两种：Range策略和Round-robin策略。Range策略会将离开的消费者处理的分区范围平均分配给其他消费者。Round-robin策略会将离开的消费者处理的分区轮流分配给其他消费者。 在进行rebalance时，Kafka会暂停消费者读取消息，待分配完成后再继续消费。这样可以确保在分配过程中不会丢失消息。而在消费者组中，每个消费者都会维护一个偏移量，用于记录自己已消费的消息的位置。因此，消费者在重新分配分区后，可以继续从之前的偏移量处开始消费消息，避免重复消费。 总之，Kafka的rebalance机制可以保证消费者组中的消费者具有相对均衡的负载，并能够在分区重新分配时保证消息的连续性与一致性。这个机制在Kafka集群中起到了重要的作用，保证了高可用性和负载均衡的特性。 ### 回答3： Kafka的Rebalance机制是指在消费者组中加入或退出一个消费者时，Kafka自动重新分配消费者与消费者之间的Topic分区。这个机制的目的是保证消费者组内的负载均衡，确保每个消费者处理大致相同数量的消息。 当一个消费者加入或退出消费者组时，Rebalance机制会触发一个重新分配分区的过程。这个过程包括以下几个步骤： 1. 消费者加入或退出：当有一个消费者加入消费者组时，或者有一个消费者退出消费者组时，Kafka会进行重新分区。加入消费者组的消费者将被分配新的分区，而退出消费者组的消费者的分区将被重新分配给其它消费者。 2. 再均衡协调者：Kafka集群中会有一个特殊的角色，称为再均衡协调者。这个角色负责协调消费者组的再均衡过程。它会与消费者组中的每个消费者进行通信，以决定每个消费者应该被分配哪些分区。 3. 再均衡算法：再均衡协调者使用一种算法来决定分配给每个消费者的分区。这个算法要考虑分区的负载均衡，保证每个消费者处理大致相同数量的消息。具体的算法可以是Round Robin轮询、Range Range、Sticky等。 4. 分区指派：再均衡协调者完成分区的指派后，将结果通知给每个消费者。消费者根据指派结果来分配并处理属于它们的分区。 总之，Kafka的Rebalance机制在消费者组中加入或退出一个消费者时，自动进行分区的重新分配，以保证负载均衡和消费者的高可用性。这个机制可以确保每个消费者处理大致相同数量的消息，提高整个消费者组的吞吐量和效率。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值