kafka分区及副本在broker的分配

部分内容参考自:http://blog.csdn.net/lizhitao/article/details/41778193

下面以一个Kafka集群中4个Broker举例,创建1个topic包含4个Partition,2 Replication;数据Producer流动如图所示:

(1)

pic

(2)当集群中新增2节点,Partition增加到6个时分布情况如下:

副本分配逻辑规则如下:

在Kafka集群中,每个Broker都有均等分配Partition的Leader机会。

上述图Broker Partition中,箭头指向为副本,以Partition-0为例:broker1中parition-0为Leader,Broker2中Partition-0为副本。

上述图种每个Broker(按照BrokerId有序)依次分配主Partition,下一个Broker为副本,如此循环迭代分配,多副本都遵循此规则。

副本分配算法如下:

将所有N Broker和待分配的i个Partition排序.

将第i个Partition分配到第(i mod n)个Broker上.

将第i个Partition的第j个副本分配到第((i + j) mod n)个Broker上.

事实上以上的算法是有误的,因为很明显,每个topic的分区0都会被分配在broker 0上,第1个分区都分配到broker 1上,直到partition的id超过broker的数据才开始从头开始重复,这样会导致前面几台机器的压力比后面的机器压力更大。

因此,kafka是先随机挑选一个broker放置分区0,然后再按顺序放置其它分区。如下图的情况:

Topic:ljh_test3 PartitionCount:10       ReplicationFactor:2     Configs:
    Topic: ljh_test3        Partition: 0    Leader: 5       Replicas: 5,6   Isr: 5,6
    Topic: ljh_test3        Partition: 1    Leader: 6       Replicas: 6,7   Isr: 6,7
    Topic: ljh_test3        Partition: 2    Leader: 7       Replicas: 7,2   Isr: 7,2
    Topic: ljh_test3        Partition: 3    Leader: 2       Replicas: 2,3   Isr: 2,3
    Topic: ljh_test3        Partition: 4    Leader: 3       Replicas: 3,4   Isr: 3,4
    Topic: ljh_test3        Partition: 5    Leader: 4       Replicas: 4,5   Isr: 4,5
    Topic: ljh_test3        Partition: 6    Leader: 5       Replicas: 5,7   Isr: 5,7
    Topic: ljh_test3        Partition: 7    Leader: 6       Replicas: 6,2   Isr: 6,2
    Topic: ljh_test3        Partition: 8    Leader: 7       Replicas: 7,3   Isr: 7,3
    Topic: ljh_test3        Partition: 9    Leader: 2       Replicas: 2,4   Isr: 2,4

这里分区0放到了broker5中,分区1–broker6,分区2—broker7….

再看一个例子:

Topic:ljh_test2 PartitionCount:10       ReplicationFactor:2     Configs:
    Topic: ljh_test2        Partition: 0    Leader: 2       Replicas: 2,7   Isr: 2,7
    Topic: ljh_test2        Partition: 1    Leader: 3       Replicas: 3,2   Isr: 3,2
    Topic: ljh_test2        Partition: 2    Leader: 4       Replicas: 4,3   Isr: 4,3
    Topic: ljh_test2        Partition: 3    Leader: 5       Replicas: 5,4   Isr: 5,4
    Topic: ljh_test2        Partition: 4    Leader: 6       Replicas: 6,5   Isr: 6,5
    Topic: ljh_test2        Partition: 5    Leader: 7       Replicas: 7,6   Isr: 7,6
    Topic: ljh_test2        Partition: 6    Leader: 2       Replicas: 2,3   Isr: 2,3
    Topic: ljh_test2        Partition: 7    Leader: 3       Replicas: 3,4   Isr: 3,4
    Topic: ljh_test2        Partition: 8    Leader: 4       Replicas: 4,5   Isr: 4,5
    Topic: ljh_test2        Partition: 9    Leader: 5       Replicas: 5,6   Isr: 5,6

版权声明:本文为博主原创文章,转载请注明来自 http://www.lujinhong.com http://blog.csdn.net/lujinhong2/

时间: 2024-10-04 02:58:48

kafka分区及副本在broker的分配的相关文章

Kafka(五)Kafka分区与副本

Kafka分区和副本都是由副本管理器所管理的,引入副本就是为了提高可用性,整个集群中如何判断代理是否存活? 一个存活的代理必须与Zookeeper保持连接,通过Zookeeper的心跳机制来实现的 作为一个Follower副本,该副本不能落后Leader副本太久(怎么算太久?)replica.lag.max.messages配置项确定的,默认为10秒. 满足上面2个条件则认为该副本或者节点处于同步中(in sync).Leader副本会追中所有同步中的节点,一旦一个节点宕机或者落后太久,Lead

kafka 分区和副本以及kafaka 执行流程,以及消息的高可用

1.Kafka概览 Apache下的项目Kafka(卡夫卡)是一个分布式流处理平台,它的流行是因为卡夫卡系统的设计和操作简单,能充分利用磁盘的顺序读写特性.kafka每秒钟能有百万条消息的吞吐量,因此很适合实时的数据流处理.例如kafka在线日志收集系统可作为flume的实时消息sink端,再通过kafka的消费者将消息实时写入hbase数据库中. 卡夫卡以topic分类对记录进行存储,每个记录包含key-value和timestamp. 1.1卡夫卡系统的组件.角色 broker: 每个正在运

kafka分区

一.topic下引入partition的作用:topic是逻辑的概念,partition是物理的概念.为了性能考虑,如果topic内的消息只存于一个broker,那这个broker会成为瓶颈,无法做到水平扩展.kafka通过算法尽可能的把partition分配到集群的不同服务器上.partition也可以理解为segment的封装.一个partition对应多个segment.一个segment包含一个数据文件和一个索引文件 二.kafka分区分配策略: partition.assignment

【kafka】单节点多broker配置

1.在进入多个broker设置之前,首先启动ZooKeeper服务器 /usr/local/zookeeper/bin/zkServer.sh start 2.复制kafka的server.properties文件 cd /usr/local/kafka/config/ cp -a server.properties server1.properties cp -a server.properties server2.properties vim server.properties ------

kafka之partition分区及副本replica升级

修改kafka的partition分区 bin/kafka-topics.sh --zookeeper datacollect-2:2181 --alter --partitions 3 --topic client-agent-1 修改kafka副本数 官网解释如下: Increasing replication factor Increasing the replication factor of an existing partition is easy. Just specify the

Kafka 分区分配计算(分区器 Partitions )

KafkaProducer在调用send方法发送消息至broker的过程中,首先是经过拦截器Inteceptors处理,然后是经过序列化Serializer处理,之后就到了Partitions阶段,即分区分配计算阶段.在某些应用场景下,业务逻辑需要控制每条消息落到合适的分区中,有些情形下则只要根据默认的分配规则即可.在KafkaProducer计算分配时,首先根据的是ProducerRecord中的partition字段指定的序号计算分区.读者有可能刚睡醒,看到这个ProducerRecord似

Kafka集群副本分配算法解析

副本分配算法如下: 将所有N Broker和待分配的i个Partition排序. 将第i个Partition分配到第(i mod n)个Broker上. 将第i个Partition的第j个副本分配到第((i + j) mod n)个Broker上. 原文地址:https://www.cnblogs.com/senlinyang/p/8398197.html

Kafka分区分配策略(Partition Assignment Strategy

问题 用过 Kafka 的同学用过都知道,每个 Topic 一般会有很多个 partitions.为了使得我们能够及时消费消息,我们也可能会启动多个 Consumer 去消费,而每个 Consumer 又会启动一个或多个streams去分别消费 Topic 里面的数据.我们又知道,Kafka 存在 Consumer Group 的概念,也就是 group.id 一样的 Consumer,这些 Consumer 属于同一个Consumer Group,组内的所有消费者协调在一起来消费订阅主题(su

Kafka分区与消费者的关系

1.  前言 我们知道,生产者发送消息到主题,消费者订阅主题(以消费者组的名义订阅),而主题下是分区,消息是存储在分区中的,所以事实上生产者发送消息到分区,消费者则从分区读取消息,那么,这里问题来了,生产者将消息投递到哪个分区?消费者组中的消费者实例之间是怎么分配分区的呢?接下来,就围绕着这两个问题一探究竟. 2.  主题的分区数设置 在server.properties配置文件中可以指定一个全局的分区数设置,这是对每个主题下的分区数的默认设置,默认是1. 当然每个主题也可以自己设置分区数量,如