Kafka的分区副本机制
目录生产者的分区写入计谋
轮询计谋
随机计谋
按key分配计谋
乱序分区
自定义分区计谋
实现步骤：
消费者组Rebalance机制
Rebalance触发时机
Rebalance的不良影响
消费者分区分配计谋
Range范围分配计谋
RoundRobin轮询计谋
Stricky粘性分配计谋
生产者的分区写入计谋
[*]轮询计谋
[*]随机计谋
[*]按key写入计谋
[*]自定义分区计谋
轮询计谋
https://img-blog.csdnimg.cn/direct/4e87c81d99f349cea20783756a83a5bd.png
默认的计谋，也是使用最多的计谋，可以最大限度保证全部的消息匀称分配到每一个分区。
如果在生产消息的时间，key为null,则使用轮询算法平衡的分配分区。
随机计谋
随机计谋，就是随机的将每条消息随机的分配到每个分区。
https://img-blog.csdnimg.cn/direct/e145b109119e4eafb40d0ad8d94ecf0b.png
按key分配计谋
按key分配计谋，有大概会出现数据倾斜，例如：某个key包含了大量的数据，因为key的值全部的数据都分配到了一个分区，造成分区的消息数量远远大于其他分区。
乱序分区
轮询和随机计谋都会导致一个问题，就是生产到kafka的数据都是乱序存储的，而按照key存储的也是肯定程度上的有序，也是局部有序，但又有大概导致数据倾斜，以是要联合实际情况取舍。
[*] 在Kafka中生产者是有写入计谋，如果topic有多个分区，就会将数据分散在不同的partition中存储
[*] 当partition数量大于1的时间，数据（消息）会打散分布在不同的partition中
[*] 如果只有一个分区，消息是有序的
自定义分区计谋
https://img-blog.csdnimg.cn/direct/c5af631fbc7d4b22b247df3d3a0f70e1.png
实现步骤：
1.自定义分区器
public class KeyWithRandomPartitioner implements Partitioner {
private Random r;
@Override
public void configure(Map<String, ?> configs) {
r = new Random();
}
@Override
public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {
// cluster.partitionCountForTopic 表示获取指定topic的分区数量
return r.nextInt(1000) % cluster.partitionCountForTopic(topic);
}
@Override
public void close() {
}
}
2.在kafka生产者配置中，自定义使用自定义分区器的类名
props.put(ProducerConfig.PARTITIONER_CLASS_CONFIG, KeyWithRandomPartitioner.class.getName());
消费者组Rebalance机制
Kafka的Rebalance称之为再平衡，是kafka确保Consumer group下全部consumer如何告竣一致，分配订阅的topic的每个分区的机制。
Rebalance触发时机
1.消费者组中consumer的个数发生变化。
例如：有新的consumer参加到消费者组，或者是某个consumer停止了。
https://img-blog.csdnimg.cn/direct/eabde104263142638c71263dcfa001e8.png
2.订阅的topic的个数发生变化
消费者可以订阅多个主题，假设当前的消费者组订阅了三个主题，但有一个主题忽然被删除了，此时也必要发生再平衡。
https://img-blog.csdnimg.cn/direct/fe4852a933d94de69f2d5cce074e7f7a.png
3.订阅的topic分区数发生变化
https://img-blog.csdnimg.cn/direct/3f9e46efa2cb4e118dc49a6288075d1a.png
Rebalance的不良影响
[*]发生Rebalance时，consumer group下的全部consumer都会和谐在一起共同参与，Kafka使用分配计谋尽大概到达最公平的分配
[*]Rebalance过程会对consumer group产生非常严峻的影响，Rebalance的过程中全部的消费者都将停止工作，直到Rebalance完成
消费者分区分配计谋
Range范围分配计谋
Range范围分配计谋是Kafka默认的分配计谋，它可以确保每个消费者消费的分区数量是平衡的。
注意：Rangle范围分配计谋是针对每个Topic的。
配置
算法公式
n = 分区数量 / 消费者数量
m = 分区数量 % 消费者数量
前m个消费者消费n+1个
剩余消费者消费n个
https://img-blog.csdnimg.cn/direct/a45dffd9e8e047d381e5ffd619a35946.png
https://img-blog.csdnimg.cn/direct/cd892cf8ef04454a9deaeeda14752325.png
RoundRobin轮询计谋
RoundRobin轮询计谋是将消费者以及消费者的所订阅的全部topic的全部partitions按照字典序排序（topic和分区的hashcode进行排序）。然后通过轮询方式逐个将分区以此分配给每个消费者。
配置
配置消费者的partition.assignment.strategy为org.apache.kafka.clients.consumer.RoundRobinAssignor
https://img-blog.csdnimg.cn/direct/ad84d6cbfc254e59b24f1767240b3de4.png
Stricky粘性分配计谋
从Kafka 0.11x开始，引入此类分配计谋，重要目标：
[*]分区分配尽大概匀称
[*]在发生rebalance的时间，分区的分配尽大概与上一次分配保持相同
没有发生rebalance时，Striky粘性分配计谋和RoundRobin分配计谋类似。
https://img-blog.csdnimg.cn/direct/bc8b85d39c8c4f2a95a75004853dd5ea.png
上面如果consumer2崩溃了，此时必要进行rebalance。如果是Range分配和轮询分配都会重新进行分配，例如：https://img-blog.csdnimg.cn/direct/227afd3a89fa46f9a63bb4f14af3056e.png
通过上图，我们发现，consumer0和consumer1原来消费的分区大多发生了改变。接下来我们再来看下粘性分配计谋。
https://img-blog.csdnimg.cn/direct/a74ac3b9c5e74cceb2ed24520e13f1e5.png
我们发现，Striky粘性分配计谋，保存rebalance之前的分配结果。如许，只是将原先consumer2负责的两个分区再匀称分配给consumer0、consumer1。如许可以明显减少系统资源的浪费，例如：之前consumer0、consumer1之前正在消费某几个分区，但由于rebalance发生，导致consumer0、consumer1必要重新消费之前正在处置处罚的分区，导致不必要的系统开销。（例如：某个事件正在进行就必须要取消了）
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]