Kafka知识点总结

你的名字 2022-12-06 01:16 284阅读 0赞

# 1. Kafka 概述 #

## 1. 定义 ##

Kafka是一个`分布式`的基于`发布/订阅模式`的`消息队列`（Message Queue），主要应用于大数据`实时`处理领域。  
在`流式计算`中，`Kafka一般用来缓存数据`，Storm通过消费Kafka的数据进行计算。

1.  Apache Kafka是一个开源消息系统，由**Scala**写成。是由Apache软件基金会开发的一个开源消息系统项目。
2.  Kafka最初是由LinkedIn公司开发，并于2011年初开源。2012年10月从Apache Incubator毕业。该项目的目标是为处理实时数据提供一个`统一`、`高通量`、`低等待`的平台。
3.  Kafka是一个分布式消息队列。Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer，消息接受者称为Consumer，此外kafka集群有多个kafka实例组成，每个实例(server)称为broker。
4.  无论是kafka集群，还是consumer都依赖于**zookeeper**集群保存一些`meta`信息，来保证系统可用性。  
    ![在这里插入图片描述][20200626101318265.png_pic_center]

Kafka存在必要性

1.  解耦：

> 允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的`接口约束`。

1.  冗余：

> 消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经`被处理完毕`，从而确保你的数据被安全的保存直到你使用完毕。

1.  扩展性：

> 因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。

1.  灵活性 & 峰值处理能力：

> 在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件`顶住突发的访问压力`，而不会因为突发的超负荷的请求而完全崩溃。

1.  可恢复性：

> 系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，**加入队列中的消息仍然可以在系统恢复后被处理**。

1.  顺序保证：

> 在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。（Kafka保证一个Partition内的消息的有序性）

1.  缓冲：

> 有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理`速度不一致`的情况。

1.  异步通信：

> 很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

## 2. 消息队列 ##

传统场景

MQ传统应用之异步处理队列。  
![在这里插入图片描述][20200623213418734.png_pic_center]

### 消息队列两种模式 ###

**(1)点对点模式（一对一，消费者主动拉取数据(不断的轮询)，消息收到后消息清除）**

消息生产者生产消息发送到Queue中，然后消息消费者从Queue中取出并且消费消息。消息被消费以后，queue中`不再`有存储，所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者，但是对一个消息而言，`只会有一个消费者可以消费`。  
![在这里插入图片描述][20200623214428179.png_pic_center]

**(2)发布/订阅模式（一对多，消费者消费数据之后不会清除消息）**

消息生产者（发布）将消息发布到topic(主题)中，同时有`多个`消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被`所有`订阅者消费。也有`主动推送`给消费者 跟消费者`主动前拉`取数据的两种模式，主动推送就考验消费者的`处理能力`，消费者拉取就要不断`轮询`查数据，`Kafka默认是拉取模式`。  
![在这里插入图片描述][20200623214957845.png_pic_center]

### Kafka 架构 ###

1.  **为了方便扩展，提高吞吐量，一个topic分为多个[partition][]**
2.  配合分区的设计，提出了消费者组的概念，组内每个消费者并行消费。
3.  为提高可用性，为每个partition增加若干副本，类似Hadoop中的HA

![在这里插入图片描述][20200626101346666.png_pic_center]

*  Producer ：消息生产者，就是向kafka broker`发`消息的客户端；
 *  Consumer ：消息消费者，向kafka broker`取`消息的客户端；
 *  Consumer Group （CG）：消费者组，由多个consumer组成。`消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响`。所有的消费者都属于某个消费者组，即`消费者组是逻辑上的一个订阅者`。
 *  Broker ：一台kafka服务器就是一个`broker`。一个集群由多个broker组成。一个broker可以容纳多个topic。
 *  Topic ：可以理解为一个`队列`，`生产者和消费者面向的都是一个topic`；
 *  Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个`partition`，每个partition是一个有序的队列，有点平衡分摊生产者机制；
 *  Replica：`副本`，为保证集群中的某个节点发生故障时，`该节点上的partition数据不丢失，且kafka仍然能够继续工作`，kafka提供了`副本`机制，一个topic的每个分区都有若干个副本，一个leader和若干个follower。
 *  leader：每个分区多个副本的`主`，生产者发送数据的对象，以及消费者消费数据的对象都是leader。
 *  follower：每个分区多个副本中的`从`，实时从leader中同步数据，保持和leader数据的同步。leader发生故障时，某个follower会成为新的follower。

# 2. Kafka 快速入门 #

## 集群规划 ##

<table> 
 <thead> 
  <tr> 
   <th>hadoop102</th> 
   <th>hadoop103</th> 
   <th>hadoop104</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>zk</td> 
   <td>zk</td> 
   <td>zk</td> 
  </tr> 
  <tr> 
   <td>kafka</td> 
   <td>kafka</td> 
   <td>kafka</td> 
  </tr> 
 </tbody> 
</table>

## Jar下载 ##

官网：[http://kafka.apache.org/downloads.html][http_kafka.apache.org_downloads.html]  
语言：[Scala][]  
![在这里插入图片描述][20200623220532516.png_pic_center]

## 安装 ##

1.  解压安装包

[atguigu@hadoop102 software]$ tar -zxvf kafka_2.11-0.11.0.0.tgz -C /opt/module/

1.  修改解压后的文件名称

[atguigu@hadoop102 module]$ mv kafka_2.11-0.11.0.0/ kafka

1.  在/opt/module/kafka目录下创建logs文件夹

[atguigu@hadoop102 kafka]$ mkdir logs

1.  修改配置文件

[atguigu@hadoop102 kafka]$ cd config/
    [atguigu@hadoop102 config]$ vi server.properties
    #broker的全局唯一编号，不能重复,集群注意修改
    broker.id=0
    #删除topic功能
    delete.topic.enable=true
    #处理网络请求的线程数量
    num.network.threads=3
    #用来处理磁盘IO的现成数量
    num.io.threads=8
    #发送套接字的缓冲区大小
    socket.send.buffer.bytes=102400
    #接收套接字的缓冲区大小
    socket.receive.buffer.bytes=102400
    #请求套接字的缓冲区大小
    socket.request.max.bytes=104857600
    #kafka运行日志存放的路径 !! 
    log.dirs=/opt/module/kafka/logs
    #topic在当前broker上的分区个数
    num.partitions=1
    #用来恢复和清理data下数据的线程数量
    num.recovery.threads.per.data.dir=1
    #segment文件保留的最长时间，超时将被删除
    log.retention.hours=168
    #配置连接Zookeeper集群地址 !! 
    zookeeper.connect=hadoop102:2181,hadoop103:2181,hadoop104:2181

1.  配置环境变量

[atguigu@hadoop102 module]$ sudo vi /etc/profile
    #KAFKA_HOME
    export KAFKA_HOME=/opt/module/kafka
    export PATH=$PATH:$KAFKA_HOME/bin
    [atguigu@hadoop102 module]$ source /etc/profile

1.  分发安装包

[atguigu@hadoop102 module]$ xsync kafka/ 注意：分发之后记得配置其他机器的环境变量

1.  broker.id修改

分别在hadoop103和hadoop104上修改配置文件/opt/module/kafka/config/server.properties中的broker.id=1、broker.id=2	注：broker.id不得重复

1.  启动集群

依次在hadoop102、hadoop103、hadoop104节点上启动kafka
    [atguigu@hadoop102 kafka]$ bin/kafka-server-start.sh -daemon config/server.properties
    [atguigu@hadoop103 kafka]$ bin/kafka-server-start.sh -daemon  config/server.properties
    [atguigu@hadoop104 kafka]$ bin/kafka-server-start.sh -daemon  config/server.properties

1.  关闭集群

[atguigu@hadoop102 kafka]$ bin/kafka-server-stop.sh stop
    [atguigu@hadoop103 kafka]$ bin/kafka-server-stop.sh stop
    [atguigu@hadoop104 kafka]$ bin/kafka-server-stop.sh stop

1.  kafka群起脚本

for i in hadoop102 hadoop103 hadoop104
    do
    echo "========== $i ==========" 
    ssh $i '/opt/module/kafka/bin/kafka-server-start.sh -daemon /opt/module/kafka/config/server.properties'
    echo $?
    done

### 命令操作 ###

hadoop102 是ZK中的`master`节点哦。

1.  查看当前服务器中的所有topic

[atguigu@hadoop102 kafka]$ bin/kafka-topics.sh --zookeeper hadoop102:2181 --list

1.  创建topic

[atguigu@hadoop102 kafka]$ bin/kafka-topics.sh --zookeeper hadoop102:2181 --create --replication-factor 3 --partitions 1 --topic first
    选项说明：
    --topic 定义topic名
    --replication-factor  定义副本数
    --partitions  定义分区数
    会在kafka指定的存储数据的路径下生成 first-0 这样的分区， 然后因为复本数是3 则会在另外两天机器上也生成个 first-0 。first-分区数
    在Hadoop中 我们3台机器也可以设置10台复本数，但是在Kafka中不可以！ replication-factor 数不可以大于集群数。

1.  删除topic

[atguigu@hadoop102 kafka]$ bin/kafka-topics.sh --zookeeper hadoop102:2181 --delete --topic first
    需要server.properties中设置delete.topic.enable=true否则只是标记删除。

1.  发送消息

[atguigu@hadoop102 kafka]$ bin/kafka-console-producer.sh --broker-list hadoop102:9092 --topic first
    >hello world
    >sowhat

1.  消费消息  
    消费者需要记录自己消费到那些数据了，用offset来记录，存储在Kafka文件系统中。

[atguigu@hadoop102 kafka]$ bin/kafka-console-consumer.sh \
    --zookeeper hadoop102:2181 --topic first
    
    [atguigu@hadoop102 kafka]$ bin/kafka-console-consumer.sh \
    --bootstrap-server hadoop102:9092 --topic first  上面会提示过时了 用这个好点
    
    [atguigu@hadoop102 kafka]$ bin/kafka-console-consumer.sh \
    --bootstrap-server hadoop102:9092 --from-beginning --topic first
    --from-beginning：会把主题中以往所有的数据都读取出来。

1.  查看某个Topic的详情

[atguigu@hadoop102 kafka]$ bin/kafka-topics.sh --zookeeper hadoop102:2181 --describe --topic first

1.  修改分区数

[atguigu@hadoop102 kafka]$ bin/kafka-topics.sh --zookeeper hadoop102:2181 --alter --topic first --partitions 6

# 3. Kafka 生成过程 #

### 写入方式 ###

producer采用`推`（push）模式将消息发布到broker，每条消息都被`追加`（append）到分区（patition）中，属于`顺序写磁盘`（顺序写磁盘效率比随机写内存要高，保障kafka吞吐率）。

### 分区（Partition） ###

消息发送时都被发送到一个topic，其本质就是一个`目录`，而topic是由一些 [Partition][partition] Logs(分区日志)组成，其组织结构如下图所示：  
![在这里插入图片描述][20200626101601795.png_pic_center]  
![在这里插入图片描述][20200626101655299.png_pic_center]  
      我们可以看到，每个Partition中的消息都是`有序`的，生产的消息被不断追加到Partition log上，其中的每一个消息都被赋予了一个唯一的`offset值`。

### 副本（Replication） ###

同一个partition可能会有多个replication（对应 server.properties 配置中的**default.replication.factor=N**）。没有replication的情况下，一旦broker 宕机，其上所有 patition 的数据都不可被消费，同时producer也不能再将数据存于其上的patition。

引入replication之后，同一个partition可能会有多个replication，而这时需要在这些replication之间选出一个leader，**producer和consumer只与这个leader交互，其它replication作为follower从leader 中复制数据**。

# 4. Kafka 深入 #

![在这里插入图片描述][20200623230001208.png_pic_center]  
       Kafka中消息是以`topic`进行分类的，生产者生产消息，消费者消费消息，都是面向topic的。**副本数包含leader**。

topic是`逻辑`上的概念，而 [partition][]是物理上的概念，**每个partition对应于一个log文件**，该log文件中存储的就是Producer生产的数据。每个分区维护着一个自己的独立offset，Producer生产的数据会被不断追加到该log文件末端，且每条数据都有自己的`offset`。消费者组中的每个消费者，都会实时记录自己消费到了哪个offset，以便出错恢复时，从上次的位置继续消费。

说白了就是存数据的时候给每个数据存储一个offset，然后这样方便消费者记录自己消费到什么地方了。  
![在这里插入图片描述][20200626092646262.png_pic_center]  
       数据存储的路径下找到对应的topic，然后里面的\*.index表示存放数据的索引，\*.log表示存储的数据。上图`数据默认存储7天`，

# The minimum age of a log file to be eligible for deletion due to age
    log.retention.hours=168

存储数据的.log 文件默认最大1G，超过大小则创建新文件。Kafka中在index文件中存储 **每个信息的序号跟起始偏移量还有数据量大小**。 甚至可能每一个信息的上述三个信息融合起来都是固定的字节类似neo4j存储， 加速查询数据。

# The maximum size of a log segment file. When this size is reached a new log segment will be created.
    log.segment.bytes=1073741824

形象理解：

> Kafka的设计也是源自生活，好比是为公路运输，不同的起始点和目的地需要修不同高速公路（主题），高速公路上可以提供多条车道（分区），流量大的公路(主题)多修几条车道(分区)保证畅通，流量小的公路少修几条车道避免浪费。收费站好比消费者，车多的时候多开几个一起收费避免堵在路上，车少的时候开几个让汽车并道就好了。

### Kafka文件存储机制 ###

![在这里插入图片描述][20200626093006656.png_pic_center]  
       由于生产者生产的消息会不断追加到log文件末尾，**为防止log文件过大导致数据定位效率低下，Kafka采取了`分片`和`索引`机制，将每个`partition`分为多个`segment`**。每个segment对应两个文件(`.index`文件和`.log`文件)。

这些文件位于一个文件夹下，该文件夹的**命名规则为：topic名称+分区序号**。

例如，first这个topic有三个分区，则其对应的文件夹为first-0,first-1,first-2。

00000000000000000000.index
    00000000000000000000.log
    00000000000000170410.index
    00000000000000170410.log
    00000000000000239430.index
    00000000000000239430.log

index和log文件以当前segment的第一条消息的`offset命名`。下图为index文件和log文件的结构示意图。

![在这里插入图片描述][20200626093133456.png_pic_center]  
       `.index`文件存储大量的`索引`信息，`.log`文件存储大量的`数据`，索引文件中的元数据指向对应数据文件中message的物理`偏移地址`(跟kaldi元数据存储一样)。

### 生产者 ###

分区策略

1.  分区的原因

> 1.  `方便在集群中扩展`，每个Partition可以通过调整以适应它所在的机器，而一个topic又可以有多个Partition组成，因此整个集群就可以适应任意大小的数据了；
> 2.  `可以提高并发`，因为可以以Partition为单位读写了。

1.  分区的原则

> 我们需要将producer发送的数据封装成一个`ProducerRecord`对象。

![在这里插入图片描述][20200626093345675.png_pic_center]

1.  指明 partition 的情况下，直接将指明的值直接作为 partiton 值；
2.  没有指明 partition 值但有 key 的情况下，将 key 的 hash 值与 topic 的 partition 数进行取余得到 partition 值；
3.  既没有 partition 值又没有 key 值的情况下，第一次调用时随机生成一个整数（后面每次调用在这个整数上自增），将这个值与 topic 可用的 partition 总数取余得到 partition 值，也就是常说的 round-robin 算法。

### 数据可靠性 ###

**    为保证producer发送的数据，能可靠的发送到指定的topic，topic的每个partition收到producer发送的数据后，都需要向producer发送ack（acknowledgement 确认字符），如果producer收到ack，就会进行下一轮的发送，否则重新发送数据**。  
![在这里插入图片描述][20200626093752347.png_pic_center]

副本数据同步策略

<table> 
 <thead> 
  <tr> 
   <th>方案</th> 
   <th>优点</th> 
   <th>缺点</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>半数以上完成同步，就发送ack</td> 
   <td>延迟低</td> 
   <td>选举新的leader时，容忍n台节点的故障，需要2n+1个副本</td> 
  </tr> 
  <tr> 
   <td>全部完成同步，才发送ack</td> 
   <td>选举新的leader时，容忍n台节点的故障，需要n+1个副本</td> 
   <td>延迟高</td> 
  </tr> 
 </tbody> 
</table>

Kafka选择了`第二种`方案，原因如下：

1.  同样为了容忍n台节点的故障，第一种方案需要2n+1个副本，而第二种方案只需要n+1个副本，而Kafka的每个分区都有大量的数据，第一种方案会造成`大量数据的冗余`。
2.  虽然第二种方案的网络延迟会比较高，但**网络延迟对Kafka的影响较小**。

### ISR ###

采用第二种方案之后，设想以下情景：leader收到数据，所有follower都开始同步数据，但有一个follower，因为某种故障，迟迟不能与leader进行同步，那leader就要`一直等`下去，直到它完成同步，才能发送ack。这个问题怎么解决呢？

Leader维护了一个动态的`in-sync replica` (ISR) set，`意为和leader保持同步的follower集合`。当ISR中的follower完成数据的同步之后，leader就会给follower发送ack。**如果follower长时间未向leader同步数据，则该follower将被踢出ISR，该时间阈值由replica.lag.time.max.ms参数设定**。Leader发生故障之后，就会从ISR中选举新的leader。ISR 老版本策略

> 1.  **ISR集合内要在规定时间内响应同步完，超时的踢出去。**
> 2.  ISR集合的数据量跟主节点的**容忍差额比如在10个以内**，可是如果我们生产者Batch发送的是12个，此时主节点就会比ISR集合内节点数据多12个，会导致ISR集合内所有都不符合要求而被踢出，然后同步后又被融入到ISR集合中，周而复始。`因此0.9版本后这个限制被取消`。

### 故障细节 ###

`LEO`：指的是每个副本最大的offset；  
`HW`：指的是消费者能见到的最大的offset，ISR队列中最小的LEO。

![在这里插入图片描述][20200626095139331.png_pic_center]  
**多个复本之间公共部分才是对Consumer 可见的。**

1.  `follower`故障  
    follower发生故障后会被临时踢出ISR，待该follower恢复后，follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。等该follower的LEO大于等于该Partition的HW，即follower追上leader之后，就可以重新加入ISR了。
2.  `leader`故障  
    leader发生故障之后，会从ISR中选出一个新的leader，之后，为保证多个副本之间的数据一致性，**其余的follower会先将各自的log文件高于HW的部分截掉**，然后从新的leader同步数据。

`注意`：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复(还要用ACK机制)。

### ACK 应答机制 ###

对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等ISR中的follower全部接收成功。  
所以Kafka为用户提供了`三种`可靠性级别，用户根据对可靠性和延迟的要求进行权衡，选择以下的配置。

1.  acks= 0：

> **producer`不等待`broker的ack**，这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经返回，当broker故障时有可能丢失数据；

1.  acks = 1;

> producer等待broker的ack，**partition的`leader落盘成功后返回ack`**，如果在follower同步成功之前leader故障，那么将会丢失数据；认为leader返回 信息就成功了。

![在这里插入图片描述][20200626094851666.png_pic_center]  
3. acks = -1;

> **producer等待broker的ack，partition的leader和follower(ISR中的)`全部落盘`成功后才返回ack**。但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成`数据重复`。leader收到信息了返回ok，follower收到信息但是发送ACK时候leader故障，此时生产者会重新给follower发送个信息。

![在这里插入图片描述][20200626095101557.png_pic_center]

Exactly Once 语义

将服务器的ACK设置为-1，可以保证Producer跟Server之间不会数据丢失，既`At Least Once`语义。相对的，将服务器的ACK = 0，可以保证生产者每条消息只被发送一次，既`At Most Once`。

At Least Once 可以保证数据不丢失但是无法保证数据不重复，At Most Once可以保证数据不重复但是无法保证数据不丢失。但是如果业务需要数据不可重复(Exactly Once)。**在0.11版本之前Kafka对此无能为力，只能让下游的消费者进行去重。0.11版后引入了一个`幂等性`，意思就是无论生产者发送多少个重复消息，Server端只会持久化一条数据，**

> At Least Once + 幂等性 = Exactly Once

要启动幂等性只需要在生产者参数中**`enable.idompotence= true`**，Kafka幂等性其实就是将原来在下游的去重操作放到了数据上游，开启幂等性的生产者在初始化时候会被分配一个PID，发送同一个Partition的消息会附带`Sequence Number`，Broker会对<PID，Partition，Sequence Number> 做缓存，以此来判断唯一性。

但是如果PID重启就会发生变化，同时不同partition也具有不同的主键，幂等性无法保证跨分区会话的`Exactly Once`。

生产者总结：

> 1.  ACK 通过(0,1,-1)来决定数据的准确可达性。
> 2.  数据同步问题引出ISR，ISR中数据对外可见性，Exactly Once

## 消费者 ##

### 1 消费方式 ###

consumer采用`pull`模式从broker中读取数据。

> push模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据consumer的消费能力以适当的速率消费消息。

pull模式不足之处是，如果kafka没有数据，消费者可能会陷入循环中，一直返回空数据。针对这一点，Kafka的消费者在消费数据时会传入一个时长参数timeout，如果当前没有数据可供消费，consumer会等待一段时间之后再返回，这段时长即为**timeout**。

### 2 分区分配策略 ###

一个`Consumer group`中有多个Consumer，一个 topic有多个partition，所以必然会涉及到partition的分配问题，即确定那个partition由哪个consumer来消费。针对多个Partition，消费者该消费哪个分区的消息？

Kafka存在消费者组 group.id 的概念，组内的所有消费者协调在一起来消费订阅的 topic 中的消息（消息可能存在于多个分区中）。那么同一个 group.id 组中的 consumer 该如何去分配它消费哪个分区里的数据。

针对下图中情况，3 个分区(test-0 ~ test-3)，3 个消费者(ConsumerA ~ C)，哪个消费者应该消费哪个分区的消息呢？？  
![在这里插入图片描述][20200626112418219.png_pic_center]

1.  对于如上这种情况，3 个分区， 3 个消费者。这 3 个消费者都会分别去消费 test 来这个 topic 的 3 个分区，也就是**每个 Consumer 会消费一个分区中**的消息。
2.  如果 4 个消费者消费 3 个分区，则会有 1 个消费者无法消费到消息；
3.  如果 2 个消费者消费 3 个分区，则会有 1 个消费者消费 2 个分区的消息。

针对这种情况，分区数 和 消费者数 之间，该如何选择？此处就涉及到 Kafka 消费端的**分区分配策略**了。

**什么是分区分配策略**  
       通过如上实例，我们能够了解到，同一个 group.id 中的消费者，对于一个 topic 中的多个 partition 中的消息消费，存在着一定的分区分配策略。

在 kafka 中，存在着两种分区分配策略。一种是 `RangeAssignor`分配策略(范围分区)，另一种是 RoundRobinAssignor分配策略(`轮询分区)`。**`默认`采用`RangeAssignor`范围分区**。 Kafka提供了消费者客户端参数 partition.assignment.strategy 用来设置消费者与订阅主题之间的分区分配策略。默认情况下，此参数的值为：org.apache.kafka.clients.consumer.RangeAssignor，即采用RangeAssignor分配策略

**[RangeAssignor][] 范围分区**

> Range 范围分区策略是对`每个 topic`而言的。首先对同一个 topic 里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。假如现在有 10 个分区，3 个消费者，排序后的分区将会是0,1,2,3,4,5,6,7,8,9；消费者排序完之后将会是C1-0,C2-0,C3-0。通过 partitions数/consumer数 来决定每个消费者应该消费几个分区。如果除不尽，那么前面几个消费者将会多消费 1 个分区。  
> 例如，10/3 = 3 余 1 ，除不尽，那么 消费者 C1-0 便会多消费 1 个分区，最终分区分配结果如下：

![在这里插入图片描述][20200626112818709.png_pic_center]  
Range 范围分区的弊端：

> 如上，只是针对 1 个 topic 而言，C1-0消费者多消费1个分区影响不是很大。如果有 N 多个 topic，那么针对每个 topic，消费者 C1-0 都将多消费 1 个分区，topic越多，C1-0 消费的分区会比其他消费者明显多消费 N 个分区。这就是 Range 范围分区的一个很明显的弊端了

由于 Range 范围分区存在的弊端，于是有了 RoundRobin 轮询分区策略，如下介绍

**RoundRobinAssignor 轮询分区**

> RoundRobin 轮询分区策略，是把所有的 partition 和所有的 consumer 都列出来，然后按照 hascode 进行排序，最后通过轮询算法来分配 partition 给到各个消费者。

轮询分区分为如下两种情况：

*  ①同一消费组内所有消费者订阅的消息都是相同的
 *  ②同一消费者组内的消费者所订阅的消息不相同

①如果同一消费组内，所有的消费者订阅的消息都是相同的，那么 RoundRobin 策略的分区分配会是均匀的。  
例如：同一消费者组中，有 3 个消费者C0、C1和C2，`都订阅`了 2 个主题 t0 和 t1，并且每个主题都有 3 个分区(p0、p1、p2)，那么所订阅的所以分区可以标识为t0p0、t0p1、t0p2、t1p0、t1p1、t1p2。最终分区分配结果如下：  
![在这里插入图片描述][20200626114126591.png_pic_center]  
       ②如果同一消费者组内，所订阅的消息是`不相同`的，那么在执行分区分配的时候，就不是完全的轮询分配，有可能会导致分区分配的不均匀。如果某个消费者没有订阅消费组内的某个 topic，那么在分配分区的时候，此**消费者将不会分配到这个 topic 的任何分区**。  
       例如：同一消费者组中，有3个消费者C0、C1和C2，他们共订阅了 3 个主题：t0、t1 和 t2，这 3 个主题分别有 1、2、3 个分区(即:t0有1个分区(p0)，t1有2个分区(p0、p1)，t2有3个分区(p0、p1、p2))，即整个消费者所订阅的所有分区可以标识为 t0p0、t1p0、t1p1、t2p0、t2p1、t2p2。具体而言，**消费者C0订阅的是主题t0，消费者C1订阅的是主题t0和t1，消费者C2订阅的是主题t0、t1和t2**，最终分区分配结果如下：  
![在这里插入图片描述][20200626114237118.png_pic_center]  
**StickyAssignor分配策略**  
       我们再来看一下 [StickyAssignor][] 策略，`sticky`这个单词可以翻译为`粘性的`，Kafka从0.11.x版本开始引入这种分配策略，它主要有两个目的：

1.  分区的分配要尽可能的均匀；
2.  分区的分配尽可能的与上次分配的保持相同。当两者发生冲突时，第一个目标优先于第二个目标。鉴于这两个目标，StickyAssignor策略的具体实现要比RangeAssignor和RoundRobinAssignor这两种分配策略要复杂很多。我们举例来看一下StickyAssignor策略的实际效果。

`触发时机`：当消费者当个数发生变化时。

### offset 维护 ###

三大因素：topic + groupConsumer + partition 来决定offset。

由于consumer在消费过程中可能会出现断电宕机等故障，consumer恢复后，需要从故障前的位置的继续消费，所以consumer需要实时记录自己消费到了哪个offset，以便故障恢复后继续消费。

![在这里插入图片描述][20200626171936568.png_pic_center]  
       **Kafka 0.9版本之前，consumer默认将offset保存在Zookeeper中，从0.9版本开始，consumer默认将offset保存在Kafka一个内置的topic中，该topic为`__consumer_offsets`。**其中内置的`__consumer_offsets`默认又50个分区，消费者消费的数据如何存放是按照`消费者组 + 哪个分区 + 哪个主题` 的Hash值来存储到 这个默认的50个分区中的。

1.  修改配置文件consumer.properties

> exclude.internal.topics=false

1.  读取offset  
    Kafka版本>= 0.11的情况下。

> bin/kafka-console-consumer.sh --topic \_\_consumer\_offsets --zookeeper hadoop102:2181 --formatter “kafka.coordinator.group.GroupMetadataManager$OffsetsMessageFormatter” --consumer.config config/consumer.properties --from-beginning

默认是Range消费策略，如果同一个Group下的消费者个数大于topic分区数则会出现有空闲消费者。

### 消费者组案例 ###

1.  需求：测试同一个消费者组中的消费者，同一时刻只能有一个消费者消费。
2.  案例实操
3.  在hadoop102、hadoop103上修改/opt/module/kafka/config/consumer.properties配置文件中的group.id属性为任意组名。

[atguigu@hadoop103 config]$ vi consumer.properties
    group.id=atguigu

1.  在hadoop102、hadoop103上分别启动消费者

[atguigu@hadoop102 kafka]$ bin/kafka-console-consumer.sh \
    --zookeeper hadoop102:2181 --topic first --consumer.config config/consumer.properties
    
    [atguigu@hadoop103 kafka]$ bin/kafka-console-consumer.sh \
    --bootstrap-server hadoop102:9092 --topic first --consumer.config config/consumer.properties

1.  在hadoop104上启动生产者

[atguigu@hadoop104 kafka]$ bin/kafka-console-producer.sh \
    --broker-list hadoop102:9092 --topic first
    >hello world

1.  查看hadoop102和hadoop103的接收者。

> 同一时刻只有一个消费者接收到消息。

### Kafka 高效读写数据 ###

分布式

分布式的并发读写数据。

顺序写磁盘

Kafka的producer生产数据，要写入到log文件中，写的过程是一直`追加`到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到600M/s，而随机写只有100K/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其`省去了大量磁头寻址的时间`。

零拷贝技术的引入

![在这里插入图片描述][20200626174444721.png_pic_center]

### Zookeeper在Kafka中的作用 ###

Kafka集群中有一个broker会被选举为Controller，负责`管理集群broker的上下线`，所有topic的`分区副本分配`和`leader选举`等工作。Controller的管理工作都是依赖于Zookeeper的。  
以下为partition的leader选举过程：

![在这里插入图片描述][20200626174858971.png_pic_center]

### Kafka 事务 ###

Kafka在高版本加入来幂等性，比如一个生产者发给三个分区分别发送10条数据，结果最后分区发送失败。如果生产者重新发布会导致PID变化了，再重新发送给三个分区每个分区10条数据。为此引入了事务。

**Producer 事务**

为了实现跨分区回话的事务，需要引入一个全局唯一的Transaction ID ,将Producer获得的PID跟 Transaction ID 绑定，这样当Producer重启后可以通过正在进行的Transaction ID 获得原来的PID。为了管理Transaction,Kafka引入了新组建Transaction Coordinator,生产者通过和Transaction Coordinator 交互获得 Transaction ID 对应任务状态，  
Transaction Coordinator还负责将所有事务写入Kafka的一个个内部Topic,这样即使整个服务重启了，由于事务状态得到保存进行，进行中的事务状态也可以得到恢复，从而继续进行。

**Consumer 事务**

上述事务机制主要是从Producer方面考虑，对于Consumer来说，事务机制保障相对较弱，无法保障Commit的信息被精确消费，由于Consumer可以通过offset读取任意信息，而不同的Segment File 声明周期不同，同一个事务中的消息可能出现重启后部分被删除的情况。

\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#

# **Kafka主要组件说明** #

### **1、kafka当中的producer说明** ###

producer主要是用于生产消息，是kafka当中的消息生产者，生产的消息通过topic进行归类，保存到kafka的broker里面去。

### **2、kafka当中的topic说明** ###

*  kafka将消息以topic为单位进行归类
 *  topic特指kafka处理的消息源（feeds of messages）的不同分类。
 *  topic是一种分类或者发布的一些列记录的名义上的名字。kafka主题始终是支持多用户订阅的；也就是说，一 个主题可以有零个，一个或者多个消费者订阅写入的数据。
 *  在kafka集群中，可以有无数的主题。
 *  生产者和消费者消费数据一般以主题为单位。更细粒度可以到分区级别。

### **3、kafka当中的partition说明** ###

kafka当中，topic是消息的归类，**一个topic可以有多个分区，每个分区保存部分topic的数据**，所有的partition当中的数据全部合并起来，就是一个topic当中的所有的数据。

> **一个broker服务下，是否可以创建多个分区？**  
> **可以的，broker数与分区数没有关系； 在kafka中，每一个分区会有一个编号：编号从0开始**

每一个分区的数据是有序的

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMxODgzMA_size_16_color_FFFFFF_t_70]  
        说明-数据是有序 如何保证一个主题下的数据是有序的？（生产是什么样的顺序，那么消费的时候也是什么样的顺序）

topic的Partition数量在创建topic时配置。

Partition数量决定了每个Consumer group中并发消费者的最大数量。

如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMxODgzMA_size_16_color_FFFFFF_t_70 1]  
        Consumer group A 有两个消费者来读取4个partition中数据；Consumer group B有四个消费者来读取4个 partition中的数据。

### **3、kafka当中partition的副本数说明** ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMxODgzMA_size_16_color_FFFFFF_t_70 2]  
        副本数（replication-factor）：控制消息保存在几个broker（服务器）上，一般情况下等于broker的个数。

> **一个broker服务下，是否可以创建多个副本因子？**  
> **不可以；创建主题时，副本因子应该小于等于可用的broker数。**

副本因子过程图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMxODgzMA_size_16_color_FFFFFF_t_70 3]  
        副本因子操作以分区为单位的。每个分区都有各自的主副本和从副本；主副本叫做leader，从副本叫做 follower（在有多个副本的情况下，kafka会为同一个分区下的所有分区，设定角色关系：一个leader和N个 follower），处于同步状态的副本叫做in-sync-replicas(ISR);

follower通过拉的方式从leader同步数据。

消费 者和生产者都是从leader读写数据，不与follower交互。

副本因子的作用：让kafka读取数据和写入数据时的可靠性。

副本因子是包含本身，同一个副本因子不能放在同一个Broker中。

如果所有的副本都挂了，生产者如果生产数据到指定分区的话，将写入不成功。

### **5、kafka当中的segment说明** ###

一个partition当中由多个segment文件组成，每个segment文件，包含两部分，**一个是.log文件，另外一个是.index文件**，其中**.log文件包含了我们发送的数据存储**，.index文件记录的是我们.log文件的数据索引值，以便于我们加快数据的查询速度。

**索引文件与数据文件的关系**

既然它们是一一对应成对出现，必然有关系。索引文件中元数据指向对应数据文件中message的物理偏移地址。

比如索引文件中3,497代表：数据文件中的第三个message,它的偏移地址为497。再来看数据文件中，Message 368772表示：在全局partiton中是第368772个message。

注：segment index file采取**稀疏索引存储**方式，它减少索引文件大小，通过mmap可以直接内存操作，稀疏索引为数据文件的每个对应message设置一个元数据指针,它比稠密索引节省了更多的存储空间，但查找起来需要消耗更多的时间。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMxODgzMA_size_16_color_FFFFFF_t_70 4]

### **6、kafka当中的partition的offset** ###

任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量）。

offset是一个long类型数字，它唯一标识了一条消息，消费者通过（offset，partition，topic）跟踪记录。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMxODgzMA_size_16_color_FFFFFF_t_70 5]

### **7、kafka分区与消费组的关系** ###

消费组： 由一个或者多个消费者组成，同一个组中的消费者对于同一条消息只消费一次。

某一个主题下的分区数，对于消费组来说，应该小于等于该主题下的分区数。

如：某一个主题有4个分区，那么消费组中的消费者应该小于4，而且最好与分区数成整数倍1 2 4同一个分区下的数据，在同一时刻，不能同一个消费组的不同消费者消费。

总结：分区数越多，同一时间可以有越多的消费者来进行消费，消费数据的速度就会越快，提高消费的性能。

### **8、kafka当中的consumer** ###

consumer是kafka当中的消费者，主要用于消费kafka当中的数据，任何一个消费者都必定需要属于某一个消费组当中，任意时刻，一个分区当中的数据，只能被kafka当中同一个消费组下面的一个线程消费。

## **重点摘要** ##

看完上面的内容，是不是感到有点乱~不用担心，体贴的博主已经将重点提取出来了，方便大家的记忆与学习ヾ(◍°∇°◍)ﾉﾞ

> 生产者（Producer）:kafka当中的消息生产者，生产的消息通过topic进行归类，保存到kafka的broker里面去  
>   
> 主题（topic）: 一个主题可以有零个，一个或者多个消费者订阅写入的数据。可以有无数个主题。  
>   
> 分区（partition）: 每一个分区的数据是有序的,多个partition之间是无需的。Partition数量决定了每个Consumer group中并发消费者的最大数量。  
>   
> 分区和消费组之间的关系：同一个组中的消费者对于同一条消息只消费一次。  
>   
>         消费者应该小于等于该主题下的分区数.  
>         Partition = 消费任务的并发度=刚刚好，每个任务读取一个partition数据  
>         Partition >消费任务的并发度=有部分消费任务读取多个分区的数据  
>         Partition < 消费任务的并发度=有部分消费任务空闲  
>         任何时候，分区中的一条数据只能被一个消费组中的一个消费任务读取。  
>   
> 总结：分区数越多，同一时间可以有越多的消费者来进行消费，消费数据的速度就会越快，提高消费的性能。  
>   
> 数据副本（Replicas）：数据副本数一般情况下小于等于broker的个数，  
>   
>         每个分区都有各自的主副本（在哪里复制的）和从副本（复制出来的）。  
>         follower通过拉的方式从leader同步数据。  
>         消费者和生产者都是从leader读写数据，不与follower交互。副本只用来提高集群的可靠性。  
>          一个分区有三个副本因子，一个挂掉（主福本），不会在其他的broker中，另启动一个副本。丢失的副本不会恢复。  
>         lsr表示：当前可用的副本列表  
>         Segment：一个partition当中有多个segment，一个segment由一个是.log文件和一个.index文件  
>         偏移量（Offset）：每条消息在文件中的位置称为offset（偏移量）  
>         消费者（Consumer）：任何一个消费者都必定需要属于某一个消费组当中。

## ##

# 其他详解 #

### **1. 什么是Kafka** ###

kafka是一个分布式，分区的，多副本的，多订阅者的消息发布订阅系统。

### **2. Kafka的使用场景** ###

应用耦合、异步处理、限流削峰、消息驱动的系统。

### **3. Kafka优缺点** ###

**优点**：

可靠性强（分布式-分区-副本）、扩展性强（可伸缩）、性能高（数据读写）、耐用性强（数据持久化）、时效性强。

**缺点**：

*  由于是批量发送，数据并非真正的实时。
 *  仅支持统一分区内消息有序，无法实现全局消息有序；
 *  有可能消息重复消费；
 *  依赖zookeeper进行元数据管理。

### **4. Kafka架构（流程）** ###

生产者、kafka集群、消费者、zookeeper

### **5. Kafka架构（API）** ###

生产者、消费者、StreamAPI、ConnectAPI

### **6.Topic内部有哪些组成？** ###

每个Topic包含一个或者多个Partition，一个partition当中存在多个segment文件段，每个segment分为两部分，.log文件和.index文件。

### **7.分区和消费组内的消费者之间的关系有哪些情况？** ###

Partition = 消费任务的并发度=刚刚好，每个任务读取一个partition数据

Partition > 消费任务的并发度=有部分消费任务读取多个分区的数据

Partition < 消费任务的并发度=有部分消费任务空闲(可以创建多于分区的消费者数量)

### **8. 分区数、消费者与读取效率之间的关系** ###

分区数越多，同一时间可以有越多的消费者来进行消费，消费数据的速度就会越快，提高消费的性能

### **9. 副本数与broker之间的关系** ###

数据副本（包含本身）数一般情况下小于等于broker的个数

### **10. 什么是主/从副本** ###

被复制的分区叫做主副本（Leader）,复制出来的叫做从副本（Follower）

### **11. 主/从复本的作用是什么** ###

主副本负责数据的读写。  
        从副本只做数据备份，不做数据读写。

### **12. Isr是什么** ###

ISR是一组与leaders完全同步的消息副本（包括leaders本身）。

### **13. 生产者生产数据到kafka集群，数据到分区的方式** ###

a)没有指定分区编号，没有指定key时采用轮询方式存储数据

b)没有指定分区编号，指定key时，数据分发策略为对key求取hash值，这个值与分区数量取余，余数就是分区编号。

c)指定分区编号，所有数据输入到指定的分区内

d)自定义分区

### **14. Consumer消费数据的流程** ###

1、首先Consumer连接指定的Topic partition所在leader broker，使用折半/二分查找，先确定数据所在的segment。

2、确定在哪个segment后，使用确定的segment内的index文件找到数据具体的位置采用pull方式从kafkalogs中获取消息。

### **15. Kafka中的数据删除机制是什么？** ###

1、时间：默认存储168小时（一周）

2、数据的大小：默认 -1 （不删除），可以自行设置。

### **16. Kafka如何保证数据不丢失** ###

从大体上来看的话，Kafka中主要的角色有数据生产者(**Producer**)，Kafka集群中负责存储数据的**Broker**，数据消费者（**Consumer**），因此这个问题需要从三个角度来进行回答!

1、生产者如何保证数据不丢失？？ 通过ack 机制确保数据不丢失。

2、kafka集群如何保证数据不丢失？？ 通过数据副本保证数据不丢失。

3、消费者如何保证数据不丢失？？ 通过维护数据的offset 保证数据不丢失。

### **17. Kafka高性能的原因有哪里** ###

顺序读写、分区、批量发送、数据压缩

### **18. Kafka高效查询数据的有哪些原因** ###

1、Kafka把topic中一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。

2、通过索引信息可以快速定位message和确定response的最大大小。

3、通过index元数据全部映射到memory，可以避免segment file的IO磁盘操作。

4、通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小。

### **19. 如何从Kafka得到准确的信息(不是重读数据)?** ###

在数据生产过程中避免重复。

在数据消耗期间避免重复。

### **20. Kafka的设计是什么样的呢？** ###

Kafka将消息以topic为单位进行归纳。将向Kafka topic发布消息的程序成为producers。将预订topics并消费消息的程序成为consumer。 Kafka以集群的方式运行，可以由一个或多个服务组成，每个服务叫做一个broker。producers通过网络将消息发送到Kafka集群，集群向消费者提供消息。

### **21. 数据传输的事物定义有哪三种？** ###

1、最多一次:消息不会被重复发送，最多被传输一次，但也有可能一次不传输，可能会造成数据丢失。

2、最少一次: 消息不会被漏发送，最少被传输一次，但也有可能被重复传输。可能会造成数据的重复消费。

3、精确的一次（Exactly once）:不会漏传输也不会重复传输,每个消息都传输被一次而且仅仅被传输一次，这是大家所期望的。

### **22. Kafka判断一个节点是否还活着有哪些条件？** ###

1、节点必须可以维护和ZooKeeper的连接，Zookeeper通过心跳机制检查每个节点的连接

2、如果节点是个follower,他必须能及时的同步leader的写操作，延时不能太久

### **23. Kafka 与传统消息系统之间有哪些区别？** ###

1、Kafka 持久化日志：这些日志可以被重复读取和无限期保留

2、Kafka 是一个分布式系统：它以集群的方式运行，可以灵活伸缩，在内部通过复制数据提升容错能力和高可用性

3、Kafka 支持实时的流式处理

### **24. Kafka创建Topic时将分区放置到不同的Broker的策略是什么？** ###

前提：副本因子不能大于 Broker 的个数；

第一个分区（编号为0）的第一个副本放置位置是随机从 brokerList 选择的；

其他分区的第一个副本放置位置相对于第0个分区依次往后移。

例如：有5个 Broker，5个分区，假设第一个分区放在第四个 Broker 上，那么第二个分区将会放在第五个 Broker 上；第三个分区将会放在第一个 Broker 上；第四个分区将会放在第二个 Broker 上，第五个分区将会放在第三个 Broker 上；

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMxODgzMA_size_16_color_FFFFFF_t_70 6]

### **25. Kafka新建的分区会在哪个目录下创建** ###

若 log.dirs 参数只配置了一个目录，那么分配到各个 Broker 上的分区将在这个目录下创建文件夹用于存放数据。

若 log.dirs 参数配置了多个目录，那么 Kafka 会在含有分区目录总数最少的文件夹中创建新的分区目录，分区目录名为 Topic名+分区ID。注意（不是磁盘使用量最少的目录）

### **26. partition的数据如何保存到硬盘** ###

topic中的多个partition以文件夹的形式保存到broker，每个分区序号从0递增， 且消息有序 Partition文件下有多个segment（xxx.index，xxx.log） segment 文件里的 大小和配置文件大小一致可以根据要求修改 默认为1g 如果大小大于1g时，会滚动一个新的segment并且以上一个segment最后一条消息的偏移量命名。

### **27. kafka的ack机制** ###

request.required.acks有三个值 0 1 -1

0:生产者不会等待broker的ack，这个延迟最低但是存储的保证最弱当server挂掉的时候就会丢数据

1：服务端会等待ack值 leader副本确认接收到消息后发送ack但是如果leader挂掉后它不确保是否复制完成新leader也会导致数据丢失

\-1：同样在1的基础上 服务端会等所有的follower的副本受到数据后才会受到leader发出的ack，这样数据不会丢失  
![在这里插入图片描述][20200324160507739.png]

### **28. Kafka的消费者如何消费数据** ###

消费者每次消费数据的时候，消费者都会记录消费的物理偏移量（offset）的位置 等到下次消费时，他会接着上次位置继续消费。同时也可以按照指定的offset进行重新消费。

### **29. 如何使kafka集群内的数据是有序的？** ###

只创建一个分区。（但是实际这样会存在性能问题，具体业务具体分析后确认。）

### **30. Zookeeper汇总保留了哪些数据？** ###

1、消费者提交的偏移量。  
        2、leader检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态  
        3、分区和消费者的所有者关  
        4、broker id

### **31. kafka consumer 什么情况会触发再平衡reblance?** ###

1、一旦消费者加入或退出消费组，导致消费组成员列表发生变化，消费组中的所有消费者都要执行再平衡。  
        2、订阅主题分区发生变化，所有消费者也都要再平衡。

### **32、描述下kafka consumer 再平衡步骤?** ###

1、关闭数据拉取线程，清空队列和消息流，提交偏移量；  
        2、释放分区所有权，删除zk中分区和消费者的所有者关系；  
        3、将所有分区重新分配给每个消费者，每个消费者都会分到不同分区；  
        4、将分区对应的消费者所有关系写入ZK，记录分区的所有权信息；  
        5、重启消费者拉取线程管理器，管理每个分区的拉取线程。

### **33. 手动提交offset有什么好处？？** ###

使更新offset更及时，避免因offset更新不及时导致重复消费数据的问题。

### **34. 为什么kafka中的数据需要定期删除或合并？** ###

Kafka只用于做数据的临时存储、临时缓冲，不是永久存储（永久性存储使用HDFS）。

# 参考 #

[https://blog.csdn.net/qq\_31821675/article/details/106932545][https_blog.csdn.net_qq_31821675_article_details_106932545]

[https://blog.csdn.net/weixin\_44318830/article/details/105014932][https_blog.csdn.net_weixin_44318830_article_details_105014932]

[https://blog.csdn.net/weixin\_44318830/article/details/105072995][https_blog.csdn.net_weixin_44318830_article_details_105072995]

[20200626101318265.png_pic_center]: /images/20221123/8172b06f63054ec489a4e87c77813b8d.png
[20200623213418734.png_pic_center]: /images/20221123/bec385085d3d4114ae7b18f66573fe9f.png
[20200623214428179.png_pic_center]: /images/20221123/59e3f7e942f74741ad17d6b9afe955fa.png
[20200623214957845.png_pic_center]: /images/20221123/1b1baa68d2524dfa9fddf13e7dedc55c.png
[partition]: https://www.zhihu.com/question/28925721
[20200626101346666.png_pic_center]: /images/20221123/c6fdfdeaced049298afd6f4560f8d467.png
[http_kafka.apache.org_downloads.html]: http://kafka.apache.org/downloads.html
[Scala]: https://blog.csdn.net/qq_31821675/category_9384246.html
[20200623220532516.png_pic_center]: /images/20221123/bdf81398202a4b57ab463088e583aa4b.png
[20200626101601795.png_pic_center]: /images/20221123/24c0ea9393d8417d8257ce8aed734d70.png
[20200626101655299.png_pic_center]: /images/20221123/0ad508adb7a54bc4a2f4c5aaa15993fc.png
[20200623230001208.png_pic_center]: /images/20221123/cab89dbeee664d0eb3689849a3677d23.png
[20200626092646262.png_pic_center]: /images/20221123/e447f56f0bff4d1e9d4bea5465651cfe.png
[20200626093006656.png_pic_center]: /images/20221123/4526e25a615e47898d7777f156598cbf.png
[20200626093133456.png_pic_center]: /images/20221123/83ba4625d9c44eb397674cbb2e038c2d.png
[20200626093345675.png_pic_center]: /images/20221123/af4f37926b6c419bb9cfa4b1f2aa530b.png
[20200626093752347.png_pic_center]: /images/20221123/172cc19b6cec415498f36454316d5b4c.png
[20200626095139331.png_pic_center]: /images/20221123/554e77437985413d84aa768fbe05920e.png
[20200626094851666.png_pic_center]: /images/20221123/a3b2147a7ba640ca88e999f6f8578f58.png
[20200626095101557.png_pic_center]: /images/20221123/3bba8c773ada4335b68490148658b2a0.png
[20200626112418219.png_pic_center]: /images/20221123/720ad6ab81f14e03a912525dbd8d57db.png
[RangeAssignor]: https://blog.csdn.net/u013256816/article/details/81123600
[20200626112818709.png_pic_center]: /images/20221123/6ff287c5de99414ea1e19899bf2786d1.png
[20200626114126591.png_pic_center]: /images/20221123/1654624b531741a3a4ddf16a017a2875.png
[20200626114237118.png_pic_center]: /images/20221123/c8f4cb9390684e0cbdaa0fb387de1231.png
[StickyAssignor]: https://blog.csdn.net/u013256816/article/details/81123625
[20200626171936568.png_pic_center]: /images/20221123/371d50e2a9424aa89ff51cf49b6e46bd.png
[20200626174444721.png_pic_center]: /images/20221123/dc0cad2125f44903a8c7f198f7314e64.png
[20200626174858971.png_pic_center]: /images/20221123/a4decfed1b844230b6cb650238681284.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMxODgzMA_size_16_color_FFFFFF_t_70]: /images/20221123/e7df0752bfec40faa0b0aa84ffff23ac.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMxODgzMA_size_16_color_FFFFFF_t_70 1]: /images/20221123/8604be9a487a4da3ad1400c06796c6c4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMxODgzMA_size_16_color_FFFFFF_t_70 2]: /images/20221123/7114513dc1ac42ee8e19761e2390799b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMxODgzMA_size_16_color_FFFFFF_t_70 3]: /images/20221123/07db9a1fc180416587445eaadc2f5d11.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMxODgzMA_size_16_color_FFFFFF_t_70 4]: /images/20221123/e77a5e3a39194781bf451a3e9f0d728d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMxODgzMA_size_16_color_FFFFFF_t_70 5]: /images/20221123/acd65ea41c54426bb81943d8ba560ccc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMxODgzMA_size_16_color_FFFFFF_t_70 6]: /images/20221123/d92fffbc82a84edbb9209a5cdb9626bc.png
[20200324160507739.png]: /images/20221123/21d5a87188dd41119d99508f08d6cc47.png
[https_blog.csdn.net_qq_31821675_article_details_106932545]: https://blog.csdn.net/qq_31821675/article/details/106932545
[https_blog.csdn.net_weixin_44318830_article_details_105014932]: https://blog.csdn.net/weixin_44318830/article/details/105014932
[https_blog.csdn.net_weixin_44318830_article_details_105072995]: https://blog.csdn.net/weixin_44318830/article/details/105072995