详细的Kafka介绍

kafka是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），本文作为我学习kafka的一个整理记录，希望能帮想要学习kafka的同学了解kafka。

 

1·kafka整体数据流图

 

2·概念介绍

 

3·Broker

Kafka通过zookeeper来指定一台Kafka broker为controller。

3.1·controller选举流程

3.2·controller选举触发条件

4·Topic

4.1·创建

1.创建topic的时候有两个参数很重要，partions和replication-factor

2.创建命令：./bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test1

1).partitions：指定topic有几个partition

2).replication-factor：topic的副本数。每个主题可以有多个副本，副本位于集群中不同的broker上，也就是说副本的数量不能超过broker的数量，否则创建主题时会失败。

例如：2个broker ，创建topic的参数为 --replication-factor 2 --partitions 3，创建的toipc分区如下：有0，1，2三个分区，每个分区有2个副本。

5·partition

5.1·副本replica

每个partion（分区）下面都有多个副本，副本分为leader和follower。

leader接受生产者写消息，接受消费者读消息。

follower不参与读写，只从leader同步数据（主动拉去leader的数据），作为备份，和kafka的读写性能无关。

如果分区下面的leader异常了，从Zookeeper中读取当前分区的所有ISR(in-sync replicas)集合， kafka通过controller选出新leader。

 

5.2·offset（偏移量）

每个partition被不同Consumer（非同一个Consumer  group）消费，每个Consumer都会有自己的offset，新的Consumer订阅topic，消费一个partition时，都是从最开始的消息消费的，当然Consumer也可以调整offset去从某个点开始消费消息。

offset概念主要有以下几个：

• Last Committed Offset ： consumer group 最新一次 commit 的 offset ，表示这个 group 已经把 Last Committed Offset 之前的数据都消费成功了。

• Current Position ： consumer group 当前消费数据的 offset ，也就是说 ， Last Committed Offset 到 Current Position 之间的数据已经拉取成功，可能正在处理，但是还未 commit 。

• Log End Offset(LEO) ：记录底层日志 (log) 中的下一条消息的 offset 。 对 producer 来说，就是即将插入下一条消息的 offset 。

• High Watermark(HW) ：已经成功备份到其他 replicas 中的最新一条数据的 offset ，也就是说 Log End Offset 与 High Watermark 之间的数据已经写入到该 partition 的 leader 中，但是还未完全备份到其他的 replicas 中 ， consumer 是无法消费这部分消息 ( 未提交 消息 ) 。

6·关键知识点

6.1·ISR

1.每个partition（分区）都有一个leader，多个follower。（都是数据的副本）

2.leader会维持一个与其保持同步的replica集合，该集合就是ISR，每一个partition都有一个ISR，它是由leader动态维护。

3.副本是有可能被踢出ISR列表的，如：

【1】长时间未向leader同步数据,则被踢出isr，该时间阈值由replica.lag.time.max.ms参数设定，单位ms。

【2】和leader的信息条数差值大于阈值，则被踢出ISR，阈值根据配置参数rerplica.lag.max.messages决定，单位条。

6.2·ACK机制

1.生产者发出消息到达分区leader之后， Leader将消息写入本地Log。Follower则从Leader pull数据。Follower在收到该消息向Leader发送ACK。一旦Leader收到了ISR中所有Replica的ACK，该消息就被认为已经commit了，Leader将增加HW并且向Producer发送ACK。   leader要确保有follower同步完成，才能发送ACK，这样才能保证leader挂掉之后，能在follower中选出可靠的新leader（注：生产者发送的消息只有在确认发送成功后 才能被消费者消费）。

2.至于多少个follower完成同步，就可以发送ack，kafka提供了三种可靠性级别的选择，由request.required.acks参数控制，参数可选值如下：

1). 0：生产者只管发送，不管服务器，消费者是否收到信息。

2). 1：只有当leader 确认了收到消息，才确认此消息发送成功。

3). -1：只有isr 中的n-1个副本（leader 除外所以n-1）都同步了消息 此消息才确认发送成功。

3.另外一个参数min.insync.replicas也很重要，只有当request.required.acks参数为-1是，才会生效。

min.insync.replicas=n 配置参数表示 当满足了n个副本的消息确认（n默认为1，最好大于1，因为leader 也在isr 列表中），才认为这条消息是发送成功的。

ISR中的副本数少于min.insync.replicas配置的数量时，客户端会返回异常：

org.apache.kafka.common.errors.NotEnoughReplicasExceptoin: Messages are rejected since there are fewer in-sync replicas than required。

ack机制也保证了数据可靠性和数据持久性

request.required.acks=-1的情况下，replication.factor>=2且min.insync.replicas>=2的情况下，不会丢失数据。