kafka基础概念三

1.kafka集群中的controller、rebalance、HW

1.controller

• 集群中谁来充当controller
  每个broker启动时会向zk创建一个临时序号节点,获得的序号最小的的那个broker将会作为集群中的controller,负责这么几件事:
• 当集群中有一个副本的leader挂掉,需要在集群中选举出一个新的leader,选举的规则是从isr集合中最左边获得。
• 当集群中有broker新增或减少,controller会同步信息给其他broker
• 当集群中有分区新增或减少,controller会同步信息给其他broker

2.Rebalance机制

• 前提:消费组中的消费者没有指明分区来消费
• 触发的条件:当消费组中的消费者和分区的关系发生变化的时付保
• 分区分配的策略:在rebalance之前,分区怎么分配会有这么三种策略
  • orange:根据公示计算得到每个消费消费哪几个分区:前面的消费者是分区总数/消费者数量+1,之后的消费者是分区总数消费者数量
  • 轮询:大家轮着来
  • sticky:粘合策略,如果需要rebalance,会在之前已分配的基础上调整,不会改变之前的分配情况。如果这个策略没有开,那么
    就要进行全部的重新分配。建议开启。

3.HW和LEO
LEO是某个副本最后消息的消息位置(log-end-offset)

HW是已完成同步的位置。消息在写入broker时,且每个broker完成这条消息的同步后,hw才会变化。在这之前消费者是消费不到条
消息的。在同步完成之后,HW更新之后,消费者才能消费到这条消息,这样的目的是防止消息的丢失。

2、Kafka线上问题优化

1.如何防止消息丢失

生产者:

• 使用同步发送
• 把ack设成1或者all,并且设置同步的分区数>=2

消费者: 把自动提交改成手动提交

2.如何防止消息的重复消费

一条消息被消费者消费多次。如果为了消息的不重复消费,而把生产效端的重试机制关闭、消费端的手动提交改成自动提交,这样反而会出
现消息丢失,那么可以直接在防治消息丢失的手段上再加上消费消息时的幂等性保证,就能解决消息的重复消费问题。
幂等性如何保证:
mysql插入业务id作为主键,主键是唯一的,所以一次只能插入一条
使用redis或zk的分布式锁(主流的方案)

3.如何做到顺序消费

发送方:在发送时将ack不能设置0,关闭重试,使用同步发送,等到发送成功再发送下一条。确保消息是顺序发送的
接收方:消息是发送到一个分区中,只能有一个消费组的消费者来接收消息。
因此,kafka的顺序消费会牺牲掉性能。