详细的Kafka介绍

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

顺便推荐我的微信公众号：龙叔18岁

 

1·kafka整体数据流图

 

2·概念介绍

 

3·Broker

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

3.1·controller选举流程

3.2·controller选举触发条件

4·Topic

4.1·创建

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

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

partitions：

        指定topic有几个partition

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

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

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

副本是有可能被踢出isr列表的，如：

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

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

6.2·ack机制

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

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

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

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

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

 

另外一个参数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的情况下，不会丢失数据。

 

推荐公众号：龙叔18岁