Kafka学习(二)------ 工作原理

一、Kafka初始化

1.Broker Leader的选举
  Kakfa Broker集群受Zookeeper管理。所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点,因为只有一个Kafka Broker会注册成功,其他的都会失败,所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller,其他的Kafka broker叫Kafka Broker follower。这个Controller会监听其他的Kafka Broker的所有信息,如果这个kafka broker controller宕机了,在zookeeper上面的那个临时节点就会消失,此时所有的kafka broker又会一起去Zookeeper上注册一个临时节点,成功在Zookeeper上注册临时节点的这个Kafka Broker会成为新的Kafka Broker Controller。

2.Broker宕机
  一旦有一个broker宕机了,这个kafka broker controller会读取该宕机broker上所有的partition在zookeeper上的状态,并选取ISR列表中的一个replica作为partition leader(如果ISR列表中的replica全挂,选一个幸存的replica作为leader; 如果该partition的所有的replica都宕机了,则将新的leader设置为-1,等待恢复,等待ISR中的任一个Replica“活”过来,并且选它作为Leader;或选择第一个“活”过来的Replica(不一定是ISR中的)作为Leader),这个broker宕机的事情,kafka controller也会通知zookeeper,zookeeper就会通知其他的kafka broker。

3.ISR(in-sync Replica)

二、消息投递

投递消息的三种模式:

  • 发送出去后即算成功,因此这种模式并不能保证消息成功投递到broker
  • 只要Master确认收到消息就算投递成功,有较好的性能和较好的可靠性。
  • 只有当Master和所有Slave都接收到消息时,才算投递成功,这种模型提供了最高的投递可靠性,但是损伤了性能;

投递消息返回值ack的三种状态

  • 当ack=1时,表示producer写partition leader成功后,broker就返回成功,无论其他的partition follower是否写成功。一旦有个broker宕机导致partition的follower和leader切换,会导致丢数据。
  • 当ack=2时,表示producer写partition leader和其他一个follower成功的时候,broker就返回成功,无论其他的partition follower是否写成功。
  • 当ack=-1时,表示只有producer全部写成功的时候,kafka broker才返回成功信息。

  producer先把message发送到partition leader,再由leader发送给其他partition follower。
在向producer发送ACK前需要保证有多少个replica已经收到该消息:根据ack配的个数而定

三、消息消费

  Kafka提供的是“At least once”模型来保证消息的可靠性。因为消息的读取进度由offset提供,offset可以由消费者自己维护也可以维护在zookeeper里,但是当消息消费后consumer挂掉,offset没有及时写回,就有可能发生重复读的情况。

四、备份

  每个partition可以在其他的kafka broker节点上存副本,以便某个kafka broker节点宕机不会影响这个kafka集群。存replica副本的方式是按照kafka broker的顺序存。例如有5个kafka broker节点,某个topic有3个partition,每个partition存2个副本,那么partition1存broker1,broker2,partition2存broker2,broker3。。。以此类推(replica副本数目不能大于kafka broker节点的数目,否则报错。这里的replica数其实就是partition的副本总数,其中包括一个leader,其他的就是copy副本)。这样如果某个broker宕机,其实整个kafka内数据依然是完整的。但是,replica副本数越高,系统虽然越稳定,但是回来带资源和性能上的下降;replica副本少的话,也会造成系统丢数据的风险。

五、消费

  同一partition的一条message只能被同一个Consumer Group内的一个Consumer消费。不能够一个consumer group的多个consumer同时消费一个partition。
  当consumer group里面的consumer数量小于这个topic下的partition数量的时候,就会出现一个conusmer thread消费多个partition的情况,总之是这个topic下的partition都会被消费。
当consumer group里面的consumer数量大于这个topic下的partition数量的时候,就会有一个consumer thread空闲。
因此,最优的设计就是,consumer group下的consumer thread的数量等于partition数量,这样效率是最高的。

六、异常

1.replica不工作

  如果这个不工作的partition replica不在ack列表中,那么producer在发送消息到partition leader上,partition leader向partition follower发送message没有响应,但不会影响整个系统。

  如果这个不工作的partition replica在ack列表中的话,producer发送的message的时候会等待这个不工作的partition replca写message成功,但是因为该partition replica没有响应导致time out,此时kafka会自动的把这个不工作的partition replica从ack列表中移除,以后的producer发送message的时候就不会有这个ack列表下的这个不工作的partition replica了。

2.replica恢复工作

​ 如果这个partition replica之前不在ack列表中,那么启动后重新受Zookeeper管理即可,之后producer发送message的时候,partition leader会继续发送message到这个partition follower上。

​ 如果这个partition replica之前在ack列表中,此时重启后,需要把这个partition replica再手动加到ack列表中。(ack列表是手动添加的,出现某个部工作的partition replica的时候自动从ack列表中移除的)

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页