分区

副本机制

spring kafka 多分区 不消费 kafka分区过多的坏处_副本机制

  • 由于Producer和Consumer都只会和Leader角色的分区副本相连,所以kafka需要以集群的
    组织形式提供主题下的消息高可用,kafka支持主备复制,所以消息具备高可用和持久性
  • 一个分区可以有多个副本,保存在不同的broker上,每个分区的副本中都有一个作为leader,当一个broker
    失败时,leader在这台broker上的分区都会变得不可用,kafka会自动移除leader,再其他副本中选一个作为新的leader
  • 在通常情况下,增加分区可以提供kafka集群的吞吐量,但是分区数过多也有不可用和延迟的风险

分区Leader选举

  • 如果分区leader挂了,follower会选举一个新的leader出来,选举方式时
    在Zookeeper上针对每个Topic维护一个ISR的集合,显然还有一些副本没有来得及同步,只有这个ISR列表
    里面才有资格成蔚leader,优先使用ISR的第一个,如果topic有f+1副本,最多可以f个不可用

分区重新分配

  • 添加kafka节点,只需要复制相应的配置文件,吧里面的broker.id修改全局唯一,最后启动节点即可
  • 把部分分区移到新添加的kafka节点上,kafka内部提供了相关的工具来和重新发布某个topic的分区
  • 借助kafka-ressign-partitions.sh工具生成reassign.plan,先定义文件,说明那些topic需要重新分区
cat reassign.json
 {“topics”:[{“topic”:“topicName”}],
 “version”:1
 }
  • 然后使用kafka-reassign-partitions.sh生成reassign plan
  • generate:表示指定类型参数
    -topic-to-move-json-file 指定分区重分配对应的主题清单路径
bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --topics-to-move-json-file
 reassign.json --broker-list “0,1,2,3(分区)” --generate
  • 此时出现两个json字符串,第一个是当前分区副本分配情况,第二个是重新分配的候选方案,还没执行
  • 将第二个json内存保存到result.json文件里面,然后执行reassign plan
  • 执行分配策略 
bin/kafka-reassign-partition.sh --zookeeper localhost:2181 --reassignment-json-file result.json --execute
  • 查看分区重新分配的进度 
bin/kafka-reassign-partition.sh --zookeeper localhost:2181 --reassignment-json-file result.json --verfy

分区分配策略

  • RangeAssignor分配策略
  • 原理是按照消费者总数和分区总数进行整除运算来获得一个跨度,然后将分区按照跨度进行平均分配,保证分区尽可能
    均匀分配给所有的消费者,
  • 按照消费者的名称的字典进行排序,然后每个消费者划分固定的分区范围,
    如果不够平均分配,字典序开钱的消费者会被多分配一个分区
  • 也就是说如果名字取的不好,容易堆积到最前面的消费者那里
  • RoundRobinAssignor
  • 将消费组里面所有的消费者和消费者订阅的所有topic的partition按照字典序排序,
    然后轮询逐个将分区分配给每个消费者
  • 但是每个分区里面的消息时不相同的,因为是轮询所以也有可能存在消费者过载的情况
  • StickyAssignor分配策略
  • 目的1:分区的分配尽可能的均匀
  • 目的2:分区的分配尽可能和上次分配的保持相同
  • 自定义分配策略
  • 需要实现PartitionAssignor接口