Kafka的Replica
概念
kafka的replica指的是消息的备份,为了保证kafka的高可用(当leader节点挂了之后,kafka依然能提供服务)kafka提供了备份的功能。这个备份是针对partition的。
可以通过 default.replication.factor 对replica的数目进行配置,默认值为1,表示不对topic进行备份。如果配置为2,表示除了leader节点,对于topic里的每一个partition,都会有一个额外的备份。
replica分配
为了起到备份的效果,简单设想下,如果让我们来分配replica,我们会怎么分配?
1)replica与所备份的节点不能再一台机器上,否则就起不到备份的效果
2)replica尽量均匀的分布在集群机器上,如果replica全部都在某几台机器上,那么一旦这台机器挂了,会丢失多个partition的备份
假设有3个broker、一个topic1、topic1有3个partition,default.replication.factor被设置为2,可能会这样分配
这种分配保证了,任何一台机器挂掉,kafka集群依然有备份可用。
replica分配算法
假设有5个broker,10个partitions,备份数设置为3
1、从一个集群的随机节点开始,轮询放置第一个replica
broker-0 | broker-1 | broker-2 | broker-3 | broker-4 | replica |
---|---|---|---|---|---|
p0 | p1 | p2 | p3 | p4 | 1st replica |
p5 | p6 | p7 | p8 | p9 | 1st replica |
2、后面的replica增加一个偏移量,继续放置,比如这里的p0,从broker-0开始,下一个replica就从broker-1开始
broker-0 | broker-1 | broker-2 | broker-3 | broker-4 | replica |
---|---|---|---|---|---|
p0(start) | p1 | p2 | p3 | p4 | 1st replica |
p5(start) | p6 | p7 | p8 | p9 | 1st replica |
p4 | p0 (start) | p1 | p2 | p3 | 2nd replica |
p8 | p9 | p5(start) | p6 | p7 | 2nd replica |
p3 | p4 | p0(start) | p1 | p2 | 3rd replica |
p7 | p8 | p9 | p5(start) | p6 | 3rd replica |
通过这种方式,replica尽可能的被均匀分配在多个broker上
多机房
上述方法,可以保证多个broker存在时,哪怕其中一个broker挂了,kafka依旧能提供服务。但是,当有多个机房时候,这种分配方式,不能保证,跨机房的高可用。
示例:4个broker,4个partition,每个partition有1个备份
按照之前的算法,replica会按照上图所示设置备份。这样假设机房1因为某个原因挂掉了,partition0的数据就会丢失掉。同理,机房2挂了,partition2也会丢失掉。
replica分配算法考虑机房
kafka可以配置一个参数broker.rack说明当前broker在哪个机房。
如上图,配置
broker0 -> rack1
broker1 -> rack1
broker2 -> rack2
broker3 -> rack2
当进行replica排序时候,不会仅仅按照broker顺序进行排序,而是会保证机房错开。比如这种情况的排序可能是
broker0,broker2,broker1,broker3
这样子排序之后,再次按照上述replica分配算法分配。
这种分配方式,保证了不同机房之间拥有全部的topic,一个机房的数据挂掉,仍然有另一个机房的数据可以使用。(前提条件,replica数目大于或等于机房的数目)
总结
kafka通过replica分配的算法保证了当某台机器挂掉,甚至某个机房挂掉,依然有备份可用。这种分配备份的算法,可以套用在需要有备份的场景,比如hdfs(没研究过,不知道是不是一样的)。
参考资料
https://community.hortonworks.com/questions/71458/can-anyone-explain-kafka-rack-awareness-feature.html
kafka源码 kafka.admin.AdminUtils#assignReplicasToBrokers