2021最新Java面经整理 | 中间件篇（二）Kafka

逃离我推掉我的手 2022-12-20 01:54 236阅读 0赞

**目录**

一、Kafka简介

1、Kafka是一个分布式流平台

2、主题和日志（Topics and Logs）（工作原理）

3、分布式

4、Kafka的优势

二、Kafka的使用场景

三、Kafka的重要概念

1、kafka的拓扑结构

2、Kafka在Zookeeper中的存储结构

五、理解好：主题（Topics）、分区（Partitions）、日志（Logs）

六、Pull 模式

七、kafka 的设计原理

1、生产者

2、消费者

3、消息传递机制

4、消息的持久化

5、消息的复制备份

6、日志（重点）

7、分配

八、Kakfa Broker Leader的选举

九、Kakfa 消息的产生和传递

1、Topic & Partition（主题和分区）

2、新增Partition的rebalance（新增分区）

3、 Partition Replica（分区的备份）

4、传递消息

十、Kafka 是如何保证数据可靠性和一致性

1、数据可靠性

2、数据一致性

十一、补充

1、Partition leader与follower

2、Topic分配partition和partition replica的算法

3、Partition ACK

4、message状态

5、message有效期

十二、其他问题

--------------------

## 一、Kafka简介 ##

Kafka是最初由Linkedin公司开发，是一个**分布式、可分区、多副本**，基于zookeeper协调的分布式消息系统。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70][]

### 1、Kafka是一个分布式流平台 ###

**1）流处理平台的特性**

*  可以让你发布和订阅流式的记录。这一方面与消息队列或者企业消息系统类似。
 *  可以储存流式的记录，并且有较好的容错性。
 *  可以在流式记录产生时就进行处理。

**2）适用场景**

*  构造实时流数据管道，它可以在系统或应用之间可靠地获取数据。 (**相当于message queue**)
 *  构建实时流式应用程序，对这些流数据进行转换或者影响。 (**类似流处理**）

**3）核心概念**

*  Kafka作为一个集群，运行在一台或者多台服务器上.
 *  Kafka 通过 *topic* 对存储的流数据进行分类。
 *  每条记录中包含一个key，一个value和一个timestamp（时间戳）

**4）四个核心 API**

*  **Producer API** ：允许应用发布一条流记录到一个或多个主题。
 *  **Consumer API** ：允许应用订阅一个或多个主题，并处理流记录。
 *  **Streams API** ：允许应用作为一个流处理器，从一个或多个主题那里消费输入流，并将输出流输出到一个或多个输出主题，从而有效地讲输入流转换为输出流。
 *  **Connector API** ：允许将主题连接到已经存在的应用或者数据系统，以构建并允许可重用的生产者或消费者。例如，一个关系型数据库的连接器可能捕获到一张表的每一次变更。

以上四个API分别对应：**发布、订阅、转换处理、从第三方采集**数据。

### 2、主题和日志（Topics and Logs）（工作原理） ###

Topic 就是数据主题，是数据记录发布的地方,可以用来区分业务系统。Kafka中的Topics总是多订阅者模式，一个topic可以拥有一个或者多个消费者来订阅它的数据。

**对于每一个topic， Kafka集群都会维持一个分区日志**，如图所示，

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 1][]

**每个分区都是一个有序的、不可变的记录序列，而且记录会不断的被追加，一条记录就是一个结构化的提交日志（a structured commit log）。**

**分区中的每条记录都被分配了一个连续的id号，这个id号被叫做offset（偏移量），这个偏移量唯一的标识出分区中的每条记录。（PS：如果把分区比作数据库表的话，那么偏移量就是主键）**

Kafka集群持久化所有已发布的记录，无论它们有没有被消费，记录被保留的时间是可以配置的。例如，如果保留策略被设置为两天，那么在记录发布后的两天内，可以使用它，之后将其丢弃以释放空间。在对数据大小方面，Kafka的性能是高效的，恒定常量级的，因此长时间存储数据不是问题。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 2][]

事实上，在每一个消费者中唯一保存的元数据是offset（偏移量）即消费在log中的位置.偏移量由消费者所控制:通常在读取记录后，消费者会以线性的方式增加偏移量，但是实际上，由于这个位置由消费者控制，所以消费者可以采用任何顺序来消费记录。例如，一个消费者可以重置到一个旧的偏移量，从而重新处理过去的数据；也可以跳过最近的记录，从"现在"开始消费。

这些细节说明Kafka 消费者是非常廉价的—消费者的增加和减少，对集群或者其他消费者没有多大的影响。比如，你可以使用命令行工具，对一些topic内容执行 tail操作，并不会影响已存在的消费者消费数据。

**日志中的 partition（分区）的用途**：

*  日志大小超过了单台服务器的限制，允许日志进行扩展。每个单独的分区都必须受限于主机的文件限制，不过一个主题可能有多个分区，因此可以处理无限量的数据。
 *  可以作为并行的单元集，并行处理，提高效率。

### 3、分布式 ###

日志的分区partition （分布）在Kafka集群的服务器上。每个服务器在处理数据和请求时，共享这些分区。每一个分区都会在已配置的服务器上进行备份，确保容错性。

每个分区都有一台 server 作为 “leader”，零台或者多台server作为 follwers 。leader server 处理一切对 partition （分区）的读写请求，而follwers只需被动的同步leader上的数据。当leader宕机了，followers 中的一台服务器会自动成为新的 leader。

**每台 server 都会成为某些分区的 leader 和某些分区的 follower，因此集群的负载是平衡的。**

### 4、Kafka的优势 ###

Kafka是一个**分布式、可分区、多副本、高吞吐**，基于zookeeper协调的分布式消息系统。

1.  高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。
2.  可扩展性：kafka集群支持热扩展
3.  持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
4.  容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）
5.  高并发：支持数千个客户端同时读写。

## 二、Kafka的使用场景 ##

Kafka主要适用的场景有：消息队列（构造实时流数据管道，它可以在系统或应用之间可靠地获取数据）、流处理（构建实时流式应用程序，请处理流数据）等。

1.  日志收集：企业可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。
2.  消息系统：解耦和生产者和消费者、缓存消息等。
3.  用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
4.  运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
5.  流式处理：比如spark streaming和storm
6.  事件源。

## 三、Kafka的重要概念 ##

Kafka中发布订阅的对象是topic。一个topic在物理上可以分为多个partition，每个partition是一个有序的队列；partition物理上由多个segment组成，每个Segment存着message信息。

我们可以为每类数据创建一个topic，把向topic发布消息的客户端称作producer，从topic订阅消息的客户端称作consumer。Producers和consumers可以同时从多个topic读写数据。一个kafka集群由一个或多个broker服务器组成，它负责持久化和备份具体的kafka消息。

> **1、Broker**
> 
> Kafka 集群包含一个或多个服务器，服务器节点称为broker。broker存储topic的数据。
> 
> **2、Topic（主题）（重点）**
> 
> Topic 就是数据主题，是数据记录发布的地方,可以用来区分业务系统。Kafka中的Topics总是多订阅者模式，一个topic可以拥有一个或者多个消费者来订阅它的数据。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）
> 
> **3、Partition（分区）（重点）**
> 
> topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。
> 
> **4、Producer（生产者）**
> 
> 生产者即数据的发布者，该角色将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息**追加**到当前用于追加数据的segment文件中。生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。
> 
> **5、Consumer（消费者）**
> 
> 消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。
> 
> **6、Consumer Group（消费组）（重点）**
> 
> 每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。如果所有的消费者实例在同一消费组中，消息记录会负载平衡到每一个消费者实例。如果所有的消费者实例在不同的消费组中，每条消息记录会广播到所有的消费者进程。
> 
> **7、Leader**
> 
> 每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。**每台 server 都会成为某些分区的 leader 和某些分区的 follower，因此集群的负载是平衡的。**
> 
> **8、Follower**
> 
> Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。如果Leader失效，则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower。

**四、Kafka的结构**

### 1、kafka的拓扑结构 ###

一个典型的Kafka集群中包含若干Producer、若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高）、若干Consumer Group，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 3][]

### 2、Kafka在Zookeeper中的存储结构 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 4][]

## 五、理解好：主题（Topics）、分区（Partitions）、日志（Logs） ##

Topic在逻辑上可以被认为是一个queue，每条消费都必须指定它的Topic，可以简单理解为必须指明把这条消息放进哪个queue里。为了使得Kafka的吞吐率可以线性提高，物理上把Topic分成一个或多个Partition，每个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索引文件。创建一个topic时，同时可以指定分区数目，分区数越多，其吞吐量也越大，但是需要的资源也越多，同时也会导致更高的不可用性，kafka在接收到生产者发送的消息之后，会根据均衡策略将消息存储到不同的分区中。因为每条消息都被append到该Partition中，属于顺序写磁盘，因此效率非常高（经验证，顺序写磁盘效率比随机写内存还要高，这是Kafka高吞吐率的一个很重要的保证）。

对于传统的message queue而言，一般会删除已经被消费的消息，而Kafka集群会保留所有的消息，无论其被消费与否。当然，因为磁盘限制，不可能永久保留所有数据（实际上也没必要），因此Kafka提供两种策略删除旧数据。一是基于时间，二是基于Partition文件大小。例如可以通过配置$KAFKA\_HOME/config/server.properties，让Kafka删除一周前的数据，也可在Partition文件超过1GB时删除旧数据，配置如下所示：

# The minimum age of a log file to be eligible for deletion
    log.retention.hours=168
    # The maximum size of a log segment file. When this size is reached a new log segment will be created.
    log.segment.bytes=1073741824
    # The interval at which log segments are checked to see if they can be deleted according to the retention policies
    log.retention.check.interval.ms=300000
    # If log.cleaner.enable=true is set the cleaner will be enabled and individual logs can then be marked for log compaction.
    log.cleaner.enable=false

因为Kafka读取特定消息的时间复杂度为O(1)，即与文件大小无关，所以这里删除过期文件与提高Kafka性能无关。选择怎样的删除策略只与磁盘以及具体的需求有关。另外，Kafka会为每一个Consumer Group保留一些metadata信息——当前消费的消息的position，也即offset。这个offset由Consumer控制。正常情况下Consumer会在消费完一条消息后递增该offset。当然，Consumer也可将offset设成一个较小的值，重新消费一些消息。因为offet由Consumer控制，所以Kafka broker是无状态的，它不需要标记哪些消息被哪些消费过，也不需要通过broker去保证同一个Consumer Group只有一个Consumer能消费某一条消息，因此也就不需要锁机制，这也为Kafka的高吞吐率提供了有力保障。

## 六、Pull 模式 ##

作为一个消息系统，Kafka遵循了传统的方式，选择**由Producer向broker push消息并由Consumer从broker pull消息**。一些logging-centric system，比如Facebook的Scribe和Cloudera的Flume，采用push模式。事实上，push模式和pull模式各有优劣。

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

**对于Kafka而言，pull模式更合适**。pull模式可简化broker的设计，Consumer可自主控制消费消息的速率，同时Consumer可以自己控制消费方式——即可批量消费也可逐条消费，同时还能选择不同的提交方式从而实现不同的传输语义。

## 七、kafka 的设计原理 ##

kafka的设计初衷是希望作为一个统一的信息收集平台,能够实时的收集反馈信息,并需要能够支撑较大的数据量,且具备良好的容错能力。

### 1、生产者 ###

负载均衡: producer将会和Topic下所有partition leader保持socket连接;消息由producer直接通过socket发送到broker,中间不会经过任何"路由层".事实上,消息被路由到哪个partition上,有producer客户端决定.比如可以采用"random""key-hash""轮询"等,如果一个topic中有多个partitions,那么在producer端实现"消息均衡分发"是必要的。

其中partition leader的位置(host:port)注册在zookeeper中,producer作为zookeeper client,已经注册了watch用来监听partition leader的变更事件。

异步发送：将多条消息暂且在客户端buffer起来，并将他们批量的发送到broker，小数据IO太多，会拖慢整体的网络延迟，批量延迟发送事实上提升了网络效率。不过这也有一定的隐患，比如说当producer失效时，那些尚未发送的消息将会丢失。

### 2、消费者 ###

consumer端向broker发送"fetch"请求,并告知其获取消息的offset;此后consumer将会获得一定条数的消息;consumer端也可以重置offset来重新消费消息。

在JMS实现中,Topic模型基于push方式,即broker将消息推送给consumer端.不过在kafka中,采用了pull方式,即consumer在和broker建立连接之后,主动去pull(或者说fetch)消息;这种模式有些优点,首先consumer端可以根据自己的消费能力适时的去fetch消息并处理,且可以控制消息消费的进度(offset);此外,消费者可以良好的控制消息消费的数量,batch fetch。

其他JMS实现,消息消费的位置是有prodiver保留,以便避免重复发送消息或者将没有消费成功的消息重发等,同时还要控制消息的状态.这就要求JMS broker需要太多额外的工作.在kafka中,partition中的消息只有一个consumer在消费,且不存在消息状态的控制,也没有复杂的消息确认机制,可见kafka broker端是相当轻量级的.当消息被consumer接收之后,consumer可以在本地保存最后消息的offset,并间歇性的向zookeeper注册offset.由此可见,consumer客户端也很轻量级。

### 3、消息传递机制 ###

对于JMS实现，消息传输担保非常直接：有且只有一次(exactly once)。在kafka中稍有不同：

*  **at most once ，消息可能会丢，但绝不会重复传输。**
 *  **at least one，消息绝不会丢，但可能会重复传输。**
 *  **exactly once ，每条消息肯定会被传输一次且仅传输一次，很多时候这是用户所想要的。**

**1）at most once**

消费者fetch消息,然后保存offset,然后处理消息;当client保存offset之后,但是在消息处理过程中出现了异常,导致部分消息未能继续处理.那么此后"未处理"的消息将不能被fetch到,这就是"at most once"。

**2）at least one**

消费者fetch消息,然后处理消息,然后保存offset.如果消息处理成功之后,但是在保存offset阶段zookeeper异常导致保存操作未能执行成功,这就导致接下来再次fetch时可能获得上次已经处理过的消息,这就是"at least once"，原因offset没有及时的提交给zookeeper，zookeeper恢复正常还是之前offset状态。

**3）exactly once**

kafka中并没有严格的去实现(基于2阶段提交,事务)，我们认为这种策略在kafka中是没有必要的。

**Kafka默认保证At least once，也是我们的首选。**Kafka允许通过设置Producer异步提交来实现At most once。而Exactly once要求与外部存储系统协作，幸运的是Kafka提供的offset可以非常直接非常容易得使用这种方式。

### 4、消息的持久化 ###

kafka使用文件存储消息,这就直接决定kafka在性能上严重依赖文件系统的本身特性.且无论任何OS下,对文件系统本身的优化几乎没有可能.文件缓存/直接内存映射等是常用的手段。**因为kafka是对日志文件进行append操作,因此磁盘检索的开支是较小的;同时为了减少磁盘写入的次数,broker会将消息暂时buffer起来,当消息的个数(或尺寸)达到一定阀值时,再flush到磁盘,这样减少了磁盘IO调用的次数。**

**kafka是线性写磁盘的，顺序写入的时间复杂度O(1)，速度非常快，磁盘线性写的速度远远大于随机写。**线性读写在大多数应用场景下是可以预测的。

### 5、消息的复制备份 ###

kafka将每个partition数据复制到多个server上,任何一个partition有一个leader和多个follower(可以没有);备份的个数可以通过broker配置文件来设定.leader处理所有的read-write请求,follower需要和leader保持同步.Follower和consumer一样,消费消息并保存在本地日志中;leader负责跟踪所有的follower状态,如果follower"落后"太多或者失效,leader将会把它从replicas同步列表中删除.当所有的follower都将一条消息保存成功,此消息才被认为是"committed",那么此时consumer才能消费它.即使只有一个replicas实例存活,仍然可以保证消息的正常发送和接收,只要zookeeper集群存活即可.(不同于其他分布式存储,比如hbase需要"多数派"存活才行)。

当leader失效时,需在followers中选取出新的leader,可能此时follower落后于leader,因此需要选择一个"up-to-date"的follower.选择follower时需要兼顾一个问题,就是新leaderserver上所已经承载的partition leader的个数,如果一个server上有过多的partition leader,意味着此server将承受着更多的IO压力.在选举新leader,需要考虑到"负载均衡"。

### 6、日志（重点） ###

如果一个topic的名称为"my\_topic",它有2个partitions,那么日志将会保存在my\_topic\_0和my\_topic\_1两个目录中;日志文件中保存了一序列"log entries"(日志条目),每个log entry格式为"4个字节的数字N表示消息的长度" + "N个字节的消息内容";每个日志都有一个offset来唯一的标记一条消息,offset的值为8个字节的数字,表示此消息在此partition中所处的起始位置..每个partition在物理存储层面,有多个log file组成(称为segment).segmentfile的命名为"最小offset".kafka.例如"00000000000.kafka";其中"最小offset"表示此segment中起始消息的offset。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 5][]

其中每个partiton中所持有的segments列表信息会存储在zookeeper中。

当segment文件尺寸达到一定阀值时(可以通过配置文件设定,默认1G),将会创建一个新的文件;当buffer中消息的条数达到阀值时将会触发日志信息flush到日志文件中,同时如果"距离最近一次flush的时间差"达到阀值时,也会触发flush到日志文件.如果broker失效,极有可能会丢失那些尚未flush到文件的消息.因为server意外失效,仍然会导致log文件格式的破坏(文件尾部),那么就要求当server启动时需要检测最后一个segment的文件结构是否合法并进行必要的修复。

获取消息时,需要指定offset和最大chunk尺寸,offset用来表示消息的起始位置,chunk size用来表示最大获取消息的总长度(间接的表示消息的条数).根据offset,可以找到此消息所在segment文件,然后根据segment的最小offset取差值,得到它在file中的相对位置,直接读取输出即可。

日志文件的删除策略非常简单:启动一个后台线程定期扫描log file列表,把保存时间超过阀值的文件直接删除(根据文件的创建时间).为了避免删除文件时仍然有read操作(consumer消费),采取copy-on-write方式。

### 7、分配 ###

kafka使用zookeeper来存储一些meta信息,并使用了zookeeper watch机制来发现meta信息的变更并作出相应的动作(比如consumer失效,触发负载均衡等)。

1.   Producer端使用zookeeper用来"发现"broker列表,以及和Topic下每个partition leader建立socket连接并发送消息。
2.   Broker端使用zookeeper用来注册broker信息,已经监测partitionleader存活性。
3.  Consumer端使用zookeeper用来注册consumer信息,其中包括consumer消费的partition列表等,同时也用来发现broker列表,并和partition leader建立socket连接,并获取消息。

## 八、Kakfa Broker Leader的选举 ##

Kakfa Broker集群受Zookeeper管理。所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。

这个Controller会监听其他的Kafka 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。如果这个kafka broker controller宕机了，在zookeeper上面的那个临时节点就会消失，此时所有的kafka broker又会一起去Zookeeper上注册一个临时节点。

**Kafka的核心是日志文件，日志文件在集群中的同步是分布式数据系统最基础的要素。**

Kafka动态维护了一个同步状态的副本的集合，简称ISR，在这个集合中的节点都是和leader保持高度一致的，任何一条消息必须被这个集合中的每个节点读取并追加到日志中了，才会通知外部这个消息已经被提交了。因此这个集合中的任何一个节点随时都可以被选为leader，ISR在ZooKeeper中维护。ISR中有f+1个节点，就可以允许在f个节点down掉的情况下不会丢失消息并正常提供服。ISR的成员是动态的，如果一个节点被淘汰了，当它重新达到“同步中”的状态时，他可以重新加入ISR，这种leader的选择方式是非常快速的，适合kafka的应用场景。

## 九、Kakfa 消息的产生和传递 ##

### 1、Topic & Partition（主题和分区） ###

Topic相当于传统消息系统MQ中的一个队列queue，producer端发送的message必须指定是发送到哪个topic，但是不需要指定topic下的哪个partition，因为kafka会把收到的message进行load balance，均匀的分布在这个topic下的不同的partition上（ hash(message) % \[partition数量\]  ）。物理上存储上，这个topic会分成一个或多个partition，每个partiton相当于是一个子queue。在物理结构上，每个partition对应一个物理的目录（文件夹），文件夹命名是\[topicname\]\_\[partition\]\_\[序号\]，一个topic可以有无数多的partition，根据业务需求和数据量来设置。在kafka配置文件中可随时更高num.partitions参数来配置更改topic的partition数量，在创建Topic时通过参数指定parittion数量。Topic创建之后通过Kafka提供的工具也可以修改partiton数量。  
一般来说，

1.  一个Topic的Partition数量大于等于Broker的数量，可以提高吞吐率。
2.  同一个Partition的备份(Replica)尽量分散到不同的机器，高可用。

### 2、新增Partition的rebalance（新增分区） ###

当新增一个partition的时候，partition里面的message不会重新进行分配，**原来的partition里面的message数据不会变，新加的这个partition刚开始是空的，随后进入这个topic的message就会重新参与所有partition的load balance。**

### 3、 Partition Replica（分区的备份） ###

每个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副本少的话，也会造成系统丢数据的风险。

### 4、传递消息 ###

**1）如何传递消息？**

Producer端使用zookeeper用来"发现"broker列表,以及和Topic下每个partition leader建立socket连接并发送消息，每个Topic下面有多个partition, 每个partition又有多个备份(Replica)，以及一个Leader，消息仅会被发送到Topic下的其中一个partition的Leader，再由Leader发送给其他partition follower。（如果让producer发送给每个replica那就太慢了）， Producer客户端自己控制着消息被推送到哪些partition leader，不需要经过任何中介或其他路由转发。为了实现这个特性，kafka集群中的每个broker都可以响应producer的请求，并返回topic的一些元信息，这些元信息包括哪些机器是存活的，topic的leader partition都在哪，现阶段哪些leader partition是可以直接被访问的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 6][]

**2）在向Producer发送ACK前需要保证有多少个Replica已经收到该消息？**

根据ack配的个数而定。

**3）怎样处理某个Replica不工作的情况？**

如果这个部工作的partition replica不在ack列表中，就是producer在发送消息到partition leader上，partition leader向partition follower发送message没有响应而已，这个不会影响整个系统，也不会有什么问题。如果这个不工作的partition replica在ack列表中的话，producer发送的message的时候会等待这个不工作的partition replca写message成功，但是会等到time out，然后返回失败因为某个ack列表中的partition replica没有响应，此时kafka会自动的把这个部工作的partition replica从ack列表中移除，以后的producer发送message的时候就不会有这个ack列表下的这个部工作的partition replica了。

**4）怎样处理Failed Replica恢复回来的情况？**

如果这个partition replica之前不在ack列表中，那么启动后重新受Zookeeper管理即可，之后producer发送message的时候，partition leader会继续发送message到这个partition follower上。如果这个partition replica之前在ack列表中，此时重启后，需要把这个partition replica再手动加到ack列表中。（ack列表是手动添加的，出现某个部工作的partition replica的时候自动从ack列表中移除的）。

## 十、Kafka 是如何保证数据可靠性和一致性 ##

### 1、数据可靠性 ###

Kafka作为一个商业级消息中间件，消息可靠性的重要性可想而知。本文从 Producter 往 Broker 发送消息、Topic 分区副本以及 Leader 选举几个角度介绍数据的可靠性。

**1）Topic 分区副本**

> 在 Kafka 0.8.0 之前，Kafka 是没有副本的概念的，那时候人们只会用 Kafka 存储一些不重要的数据，因为没有副本，数据很可能会丢失。但是随着业务的发展，支持副本的功能越来越强烈，所以为了保证数据的可靠性，Kafka 从 0.8.0 版本开始引入了分区副本。也就是说每个分区可以人为的配置几个副本（比如创建主题的时候指定 `replication-factor`，也可以在 Broker 级别进行配置 `default.replication.factor`），一般会设置为3。
> 
> Kafka 可以保证单个分区里的事件是有序的，分区可以在线（可用），也可以离线（不可用）。在众多的分区副本里面有一个副本是 Leader，其余的副本是 follower，所有的读写操作都是经过 Leader 进行的，同时 follower 会定期地去 leader 上的复制数据。当 Leader 挂了的时候，其中一个 follower 会重新成为新的 Leader。通过分区副本，引入了数据冗余，同时也提供了 Kafka 的数据可靠性。
> 
> **Kafka 的分区多副本架构是 Kafka 可靠性保证的核心，把消息写入多个副本可以使 Kafka 在发生崩溃时仍能保证消息的持久性。**

**2）Producer 往 Broker 发送消息**

> 如果我们要往 Kafka 对应的主题发送消息，我们需要通过 Producer 完成。前面我们讲过 Kafka 主题对应了多个分区，每个分区下面又对应了多个副本；为了让用户设置数据可靠性， Kafka 在 Producer 里面提供了消息确认机制。也就是说我们可以通过配置来决定消息发送到对应分区的几个副本才算消息发送成功。可以在定义 Producer 时通过 `acks` 参数指定（在 0.8.2.X 版本之前是通过 `request.required.acks` 参数设置的，详见 [KAFKA-3043][]）。这个参数支持以下三种值：
> 
>  *  acks = 0：意味着如果生产者能够通过网络把消息发送出去，那么就认为消息已成功写入 Kafka 。在这种情况下还是有可能发生错误，比如发送的对象无能被序列化或者网卡发生故障，但如果是分区离线或整个集群长时间不可用，那就不会收到任何错误。在 acks=0 模式下的运行速度是非常快的（这就是为什么很多基准测试都是基于这个模式），你可以得到惊人的吞吐量和带宽利用率，不过如果选择了这种模式， 一定会丢失一些消息。
>  *  acks = 1：意味若 Leader 在收到消息并把它写入到分区数据文件（不一定同步到磁盘上）时会返回确认或错误响应。在这个模式下，如果发生正常的 Leader 选举，生产者会在选举时收到一个 LeaderNotAvailableException 异常，如果生产者能恰当地处理这个错误，它会重试发送悄息，最终消息会安全到达新的 Leader 那里。不过在这个模式下仍然有可能丢失数据，比如消息已经成功写入 Leader，但在消息被复制到 follower 副本之前 Leader发生崩溃。
>  *  acks = all（这个和 request.required.acks = -1 含义一样）：意味着 Leader 在返回确认或错误响应之前，会等待所有同步副本都收到悄息。如果和 `min.insync.replicas` 参数结合起来，就可以决定在返回确认前至少有多少个副本能够收到悄息，生产者会一直重试直到消息被成功提交。不过这也是最慢的做法，因为生产者在继续发送其他消息之前需要等待所有副本都收到当前的消息。
> 
> 根据实际的应用场景，我们设置不同的 `acks`，以此保证数据的可靠性。
> 
> 另外，Producer 发送消息还可以选择同步（默认，通过 `producer.type=sync` 配置） 或者异步（`producer.type=async`）模式。如果设置成异步，虽然会极大的提高消息发送的性能，但是这样会增加丢失数据的风险。如果需要确保消息的可靠性，必须将 `producer.type` 设置为 sync。

**3）Leader 选举**

> 在介绍 Leader 选举之前，让我们先来了解一下 ISR（in-sync replicas）列表。每个分区的 leader 会维护一个 ISR 列表，ISR 列表里面就是 follower 副本的 Borker 编号，只有跟得上 Leader 的 follower 副本才能加入到 ISR 里面。只有 ISR 里的成员才有被选为 leader 的可能。
> 
> 所以当 Leader 挂掉了，而且 `unclean.leader.election.enable=false` 的情况下，Kafka 会从 ISR 列表中选择第一个 follower 作为新的 Leader，因为这个分区拥有最新的已经 committed 的消息。通过这个可以保证已经 committed 的消息的数据可靠性。
> 
> 综上所述，为了保证数据的可靠性，我们最少需要配置一下几个参数：
> 
>  *  producer 级别：acks=all（或者 request.required.acks=-1），同时发生模式为同步 producer.type=sync
>  *  topic 级别：设置 replication.factor>=3，并且 min.insync.replicas>=2；
>  *  broker 级别：关闭不完全的 Leader 选举，即 unclean.leader.election.enable=false；

### 2、数据一致性 ###

这里介绍的数据一致性主要是说不论是老的 Leader 还是新选举的 Leader，Consumer 都能读到一样的数据。那么 Kafka 是如何实现的呢？

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 7][]

> 假设分区的副本为3，其中副本0是 Leader，副本1和副本2是 follower，并且在 ISR 列表里面。虽然副本0已经写入了 Message4，但是 Consumer 只能读取到 Message2。因为所有的 ISR 都同步了 Message2，只有 High Water Mark 以上的消息才支持 Consumer 读取，而 High Water Mark 取决于 ISR 列表里面偏移量最小的分区，对应于上图的副本2，这个很类似于木桶原理。
> 
> 这样做的原因是还没有被足够多副本复制的消息被认为是“不安全”的，如果 Leader 发生崩溃，另一个副本成为新 Leader，那么这些消息很可能丢失了。如果我们允许消费者读取这些消息，可能就会破坏一致性。试想，一个消费者从当前 Leader（副本0） 读取并处理了 Message4，这个时候 Leader 挂掉了，选举了副本1为新的 Leader，这时候另一个消费者再去从新的 Leader 读取消息，发现这个消息其实并不存在，这就导致了数据不一致性问题。
> 
> 当然，引入了 High Water Mark 机制，会导致 Broker 间的消息复制因为某些原因变慢，那么消息到达消费者的时间也会随之变长（因为我们会先等待消息复制完毕）。延迟时间可以通过参数 `replica.lag.time.max.ms` 参数配置，它指定了副本在复制消息时可被允许的最大延迟时间。

## 十一、补充 ##

### 1、Partition leader与follower ###

partition也有leader和follower之分。leader是主partition，producer写kafka的时候先写partition leader，再由partition leader push给其他的partition follower。partition leader与follower的信息受Zookeeper控制，一旦partition leader所在的broker节点宕机，zookeeper会冲其他的broker的partition follower上选择follower变为parition leader。

### 2、Topic分配partition和partition replica的算法 ###

*  将Broker（size=n）和待分配的Partition排序。
 *  将第i个Partition分配到第（i%n）个Broker上。
 *  将第i个Partition的第j个Replica分配到第（(i + j) % n）个Broker上。

### 3、**Partition ACK** ###

当ack=1，表示producer写partition leader成功后，broker就返回成功，无论其他的partition follower是否写成功。当ack=2，表示producer写partition leader和其他一个follower成功的时候，broker就返回成功，无论其他的partition follower是否写成功。当ack=-1\[parition的数量\]的时候，表示只有producer全部写成功的时候，才算成功，kafka broker才返回成功信息。**这里需要注意的是，如果ack=1的时候，一旦有个broker宕机导致partition的follower和leader切换，会导致丢数据。**

### 4、message状态 ###

在Kafka中，消息的状态被保存在consumer中，**broker不会关心哪个消息被消费了被谁消费了，只记录一个offset值（指向partition中下一个要被消费的消息位置）**，这就意味着如果consumer处理不好的话，broker上的一个消息可能会被消费多次。

### 5、message有效期 ###

Kafka会保留其中的消息（可设置时间或大小阈值来删除），以便consumer可以多次消费，当然其中很多细节是可配置的。

1.  不是严格的JMS， 因此kafka对消息的重复、丢失、错误以及顺序型没有严格的要求。**（这是与AMQ最大的区别，所以没有用在支付领域）**
2.  kafka提供at-least-once delivery,即当consumer宕机后，有些消息可能会被重复delivery。
3.  因每个partition只会被consumer group内的一个consumer消费，故kafka保证每个partition内的消息会被顺序的订阅。
4.  Kafka为每条消息为每条消息计算CRC校验，用于错误检测，crc校验不通过的消息会直接被丢弃掉。

## 十二、其他问题 ##

### 1、Kafka 都有哪些特点？ ###

>  *  高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。
>  *  可扩展性：kafka集群支持热扩展
>  *  持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
>  *  容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）
>  *  高并发：支持数千个客户端同时读写

### 2、请简述下你在哪些场景下会选择 Kafka？ ###

>  *  日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、HBase、Solr等。
>  *  消息系统：解耦和生产者和消费者、缓存消息等。
>  *  用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
>  *  运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
>  *  流式处理：比如spark streaming和 Flink

### 3、 Kafka 的设计架构你知道吗？ ###

简单架构如下：

![20201109135248154.png][]

详细如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 8][]

Kafka 架构分为以下几个部分

>  *  Producer ：消息生产者，就是向 kafka broker 发消息的客户端。
>  *  Consumer ：消息消费者，向 kafka broker 取消息的客户端。
>  *  Topic ：可以理解为一个队列，一个 Topic 又分为一个或多个分区。
>  *  Consumer Group：这是 kafka 用来实现一个 topic 消息的广播（发给所有的 consumer）和单播（发给任意一个 consumer）的手段。一个 topic 可以有多个 Consumer Group。
>  *  Broker ：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。
>  *  Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker上，每个 partition 是一个有序的队列。partition 中的每条消息都会被分配一个有序的id（offset）。将消息发给 consumer，kafka 只保证按一个 partition 中的消息的顺序，不保证一个 topic 的整体（多个 partition 间）的顺序。
>  *  Offset：kafka 的存储文件都是按照 offset.kafka 来命名，用 offset 做名字的好处是方便查找。例如你想找位于 2049 的位置，只要找到 2048.kafka 的文件即可。当然 the first offset 就是 00000000000.kafka。

### 4、Kafka 分区的目的？ ###

分区对于 Kafka 集群的好处是：实现负载均衡。分区对于消费者来说，可以提高并发度，提高效率。

### 5、你知道 Kafka 是如何做到消息的有序性？ ###

kafka 中的每个 partition 中的消息在写入时都是有序的，而且单独一个 partition 只能由一个消费者去消费，可以在里面保证消息的顺序性。但是分区之间的消息是不保证有序的。

### 7、请谈一谈 Kafka 数据一致性原理 ###

一致性就是说不论是老的 Leader 还是新选举的 Leader，Consumer 都能读到一样的数据。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 9][]

假设分区的副本为3，其中副本0是 Leader，副本1和副本2是 follower，并且在 ISR 列表里面。虽然副本0已经写入了 Message4，但是 Consumer 只能读取到 Message2。因为所有的 ISR 都同步了 Message2，只有 High Water Mark 以上的消息才支持 Consumer 读取，而 High Water Mark 取决于 ISR 列表里面偏移量最小的分区，对应于上图的副本2，这个很类似于木桶原理。

这样做的原因是还没有被足够多副本复制的消息被认为是“不安全”的，如果 Leader 发生崩溃，另一个副本成为新 Leader，那么这些消息很可能丢失了。如果我们允许消费者读取这些消息，可能就会破坏一致性。试想，一个消费者从当前 Leader（副本0） 读取并处理了 Message4，这个时候 Leader 挂掉了，选举了副本1为新的 Leader，这时候另一个消费者再去从新的 Leader 读取消息，发现这个消息其实并不存在，这就导致了数据不一致性问题。

当然，引入了 High Water Mark 机制，会导致 Broker 间的消息复制因为某些原因变慢，那么消息到达消费者的时间也会随之变长（因为我们会先等待消息复制完毕）。延迟时间可以通过参数 replica.lag.time.max.ms 参数配置，它指定了副本在复制消息时可被允许的最大延迟时间。

### 8、ISR、OSR、AR 是什么？ ###

> ISR：In-Sync Replicas 副本同步队列
> 
> OSR：Out-of-Sync Replicas
> 
> AR：Assigned Replicas 所有副本
> 
> ISR是由leader维护，follower从leader同步数据有一些延迟（具体可以参见 图文了解 Kafka 的副本复制机制），超过相应的阈值会把 follower 剔除出 ISR, 存入OSR（Out-of-Sync Replicas ）列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR。

### 9、LEO、HW、LSO、LW等分别代表什么 ###

>  *  LEO：是 LogEndOffset 的简称，代表当前日志文件中下一条
>  *  HW：水位或水印（watermark）一词，也可称为高水位(high watermark)，通常被用在流式处理领域（比如Apache Flink、Apache Spark等），以表征元素或事件在基于时间层面上的进度。在Kafka中，水位的概念反而与时间无关，而是与位置信息相关。严格来说，它表示的就是位置信息，即位移（offset）。取 partition 对应的 ISR中 最小的 LEO 作为 HW，consumer 最多只能消费到 HW 所在的位置上一条信息。
>  *  LSO：是 LastStableOffset 的简称，对未完成的事务而言，LSO 的值等于事务中第一条消息的位置(firstUnstableOffset)，对已完成的事务而言，它的值同 HW 相同
>  *  LW：Low Watermark 低水位, 代表 AR 集合中最小的 logStartOffset 值。

### 12、消费者和消费者组有什么关系？ ###

每个消费者从属于消费组。具体关系如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 10][]

### 14、数据传输的事务有几种？ ###

数据传输的事务定义通常有以下三种级别：

>  *  最多一次: 消息不会被重复发送，最多被传输一次，但也有可能一次不传输
>  *  最少一次: 消息不会被漏发送，最少被传输一次，但也有可能被重复传输.
>  *  精确的一次（Exactly once）: 不会漏传输也不会重复传输,每个消息都传输被

### 15、Kafka 消费者是否可以消费指定分区消息？ ###

> Kafa consumer消费消息时，向broker发出fetch请求去消费特定分区的消息，consumer指定消息在日志中的偏移量（offset），就可以消费从这个位置开始的消息，customer拥有了offset的控制权，可以向后回滚去重新消费之前的消息，这是很有意义的。

### 16、Kafka消息是采用Pull模式，还是Push模式？ ###

> Kafka最初考虑的问题是，customer应该从brokes拉取消息还是brokers将消息推送到consumer，也就是pull还push。在这方面，Kafka遵循了一种大部分消息系统共同的传统的设计：producer将消息推送到broker，consumer从broker拉取消息。
> 
> 一些消息系统比如Scribe和Apache Flume采用了push模式，将消息推送到下游的consumer。这样做有好处也有坏处：由broker决定消息推送的速率，对于不同消费速率的consumer就不太好处理了。消息系统都致力于让consumer以最大的速率最快速的消费消息，但不幸的是，push模式下，当broker推送的速率远大于consumer消费的速率时，consumer恐怕就要崩溃了。最终Kafka还是选取了传统的pull模式。  
> Pull模式的另外一个好处是consumer可以自主决定是否批量的从broker拉取数据。Push模式必须在不知道下游consumer消费能力和消费策略的情况下决定是立即推送每条消息还是缓存之后批量推送。如果为了避免consumer崩溃而采用较低的推送速率，将可能导致一次只推送较少的消息而造成浪费。Pull模式下，consumer就可以根据自己的消费能力去决定这些策略。  
> Pull有个缺点是，如果broker没有可供消费的消息，将导致consumer不断在循环中轮询，直到新消息到t达。为了避免这点，Kafka有个参数可以让consumer阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特定的量这样就可以批量发。

### 19、Kafka 高效文件存储设计特点 ###

>  *  Kafka把topic中一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。
>  *  通过索引信息可以快速定位message和确定response的最大大小。
>  *  通过index元数据全部映射到memory，可以避免segment file的IO磁盘操作。
>  *  通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小

### 20、Kafka创建Topic时如何将分区放置到不同的Broker中 ###

>  *  副本因子不能大于 Broker 的个数；
>  *  第一个分区（编号为0）的第一个副本放置位置是随机从 `brokerList` 选择的；
>  *  其他分区的第一个副本放置位置相对于第0个分区依次往后移。也就是如果我们有5个 Broker，5个分区，假设第一个分区放在第四个 Broker 上，那么第二个分区将会放在第五个 Broker 上；第三个分区将会放在第一个 Broker 上；第四个分区将会放在第二个 Broker 上，依次类推；
>  *  剩余的副本相对于第一个副本放置位置其实是由 `nextReplicaShift` 决定的，而这个数也是随机产生的；

### 21、Kafka新建的分区会在哪个目录下创建 ###

> 我们知道，在启动 Kafka 集群之前，我们需要配置好 `log.dirs` 参数，其值是 Kafka 数据的存放目录，这个参数可以配置多个目录，目录之间使用逗号分隔，通常这些目录是分布在不同的磁盘上用于提高读写性能。当然我们也可以配置 `log.dir` 参数，含义一样。只需要设置其中一个即可。
> 
> 如果 `log.dirs` 参数只配置了一个目录，那么分配到各个 Broker 上的分区肯定只能在这个目录下创建文件夹用于存放数据。
> 
> 但是如果 `log.dirs` 参数配置了多个目录，那么 Kafka 会在哪个文件夹中创建分区目录呢？答案是：Kafka 会在含有分区目录最少的文件夹中创建新的分区目录，分区目录名为 Topic名+分区ID。注意，是分区文件夹总数最少的目录，而不是磁盘使用量最少的目录！也就是说，如果你给 `log.dirs` 参数新增了一个新的磁盘，新的分区目录肯定是先在这个新的磁盘上创建直到这个新的磁盘目录拥有的分区目录不是最少为止。

### 22、谈一谈 Kafka 的再均衡 ###

> 在Kafka中，当有新消费者加入或者订阅的topic数发生变化时，会触发Rebalance(再均衡：在同一个消费者组当中，分区的所有权从一个消费者转移到另外一个消费者)机制，Rebalance顾名思义就是重新均衡消费者消费。Rebalance的过程如下：
> 
> 第一步：所有成员都向coordinator发送请求，请求入组。一旦所有成员都发送了请求，coordinator会从中选择一个consumer担任leader的角色，并把组成员信息以及订阅信息发给leader。  
> 第二步：leader开始分配消费方案，指明具体哪个consumer负责消费哪些topic的哪些partition。一旦完成分配，leader会将这个方案发给coordinator。coordinator接收到分配方案之后会把方案发给各个consumer，这样组内的所有成员就都知道自己应该消费哪些分区了。  
> 所以对于Rebalance来说，Coordinator起着至关重要的作用

### 23、谈谈 Kafka 分区分配策略 ###

> 在 Kafka 内部存在两种默认的分区分配策略：Range 和 RoundRobin。当以下事件发生时，Kafka 将会进行一次分区分配：
> 
>  *  同一个 Consumer Group 内新增消费者
>  *  消费者离开当前所属的Consumer Group，包括shuts down 或 crashes
>  *  订阅的主题新增分区
> 
> 将分区的所有权从一个消费者移到另一个消费者称为重新平衡（rebalance），如何rebalance就涉及到分区分配策略。

### 25、 Kafka 是如何实现高吞吐率的？ ###

Kafka是分布式消息系统，需要处理海量的消息，Kafka的设计是把所有的消息都写入速度低容量大的硬盘，以此来换取更强的存储能力，但实际上，使用硬盘并没有带来过多的性能损失。kafka主要使用了以下几个方式实现了超高的吞吐率：

>  *  顺序读写；
>  *  零拷贝
>  *  文件分段
>  *  批量发送
>  *  数据压缩。

### 27、如何为Kafka集群选择合适的Topics/Partitions数量 ###

>  *  越多的分区可以提供更高的吞吐量
>  *  越多的分区需要打开更多地文件句柄
>  *  越多地分区会导致更高的不可用性
>  *  越多的分区可能增加端对端的延迟
>  *  越多的partition意味着需要客户端需要更多的内存

### 28、谈谈你对 Kafka 事务的了解？ ###

>  *  `PID`与`Sequence Number`的引入实现了写操作的幂等性
>  *  写操作的幂等性结合`At Least Once`语义实现了单一Session内的`Exactly Once`语义
>  *  `Transaction Marker`与`PID`提供了识别消息是否应该被读取的能力，从而实现了事务的隔离性
>  *  Offset的更新标记了消息是否被读取，从而将对读操作的事务处理转换成了对写（Offset）操作的事务处理
>  *  Kafka事务的本质是，将一组写操作（如果有）对应的消息与一组读操作（如果有）对应的Offset的更新进行同样的标记（即`Transaction Marker`）来实现事务中涉及的所有读写操作同时对外可见或同时对外不可见
>  *  Kafka只提供对Kafka本身的读写操作的事务性，不提供包含外部系统的事务性

### 29、谈谈你对 Kafka 幂等的了解？ ###

> 为了实现Producer的幂等性，Kafka引入了Producer ID（即PID）和Sequence Number。
> 
>  *  PID。每个新的Producer在初始化的时候会被分配一个唯一的PID，这个PID对用户是不可见的。
>  *  Sequence Numbler。（对于每个PID，该Producer发送数据的每个<Topic, Partition>都对应一个从0开始单调递增的Sequence Number
> 
> Kafka可能存在多个生产者，会同时产生消息，但对Kafka来说，只需要保证每个生产者内部的消息幂等就可以了，所有引入了PID来标识不同的生产者。
> 
> 对于Kafka来说，要解决的是生产者发送消息的幂等问题。也即需要区分每条消息是否重复。  
> Kafka通过为每条消息增加一个Sequence Numbler，通过Sequence Numbler来区分每条消息。每条消息对应一个分区，不同的分区产生的消息不可能重复。所有Sequence Numbler对应每个分区
> 
> Broker端在缓存中保存了这seq number，对于接收的每条消息，如果其序号比Broker缓存中序号大于1则接受它，否则将其丢弃。这样就可以实现了消息重复提交了。但是，只能保证单个Producer对于同一个<Topic, Partition>的Exactly Once语义。不能保证同一个Producer一个topic不同的partion幂等。

### 30、Kafka 缺点？ ###

>  *  由于是批量发送，数据并非真正的实时；
>  *  对于mqtt协议不支持；
>  *  不支持物联网传感数据直接接入；
>  *  仅支持统一分区内消息有序，无法实现全局消息有序；
>  *  监控不完善，需要安装插件；
>  *  依赖zookeeper进行元数据管理；

### 31、Kafka 分区数可以增加或减少吗？为什么？ ###

> 我们可以使用 bin/kafka-topics.sh 命令对 Kafka 增加 Kafka 的分区数据，但是 Kafka 不支持减少分区数。  
> Kafka 分区数据不支持减少是由很多原因的，比如减少的分区其数据放到哪里去？是删除，还是保留？删除的话，那么这些没消费的消息不就丢了。如果保留这些消息如何放到其他分区里面？追加到其他分区后面的话那么就破坏了 Kafka 单个分区的有序性。如果要保证删除分区数据插入到其他分区保证有序性，那么实现起来逻辑就会非常复杂。

### **32、Kafka 存储在硬盘上的消息格式是什么？** ###

消息由一个固定长度的头部和可变长度的字节数组组成。头部包含了一个版本号和 CRC32校验码。

>  *  消息长度: 4 bytes (value: 1+4+n)
>  *  版本号: 1 byte
>  *  CRC 校验码: 4 bytes
>  *  具体的消息: n bytes

### **33、Kafka 高效文件存储设计特点** ###

>  *  Kafka 把 topic 中一个 parition 大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。
>  *  通过索引信息可以快速定位 message 和确定 response 的最大大小。
>  *  通过 index 元数据全部映射到 memory，可以避免 segment file 的 IO 磁盘操作。
>  *  通过索引文件稀疏存储，可以大幅降低 index 文件元数据占用空间大小。

### **34、Kafka 与传统消息系统之间有三个关键区别** ###

>  *  Kafka 持久化日志，这些日志可以被重复读取和无限期保留
>  *  Kafka 是一个分布式系统：它以集群的方式运行，可以灵活伸缩，在内部通过复制数据，提升容错能力和高可用性
>  *  Kafka 支持实时的流式处理

### **35、Kafka 创建 Topic 时如何将分区放置到不同的 Broker 中** ###

>  *  副本因子不能大于 Broker 的个数；
>  *  第一个分区（编号为 0）的第一个副本放置位置是随机从 brokerList 选择的；
>  *  其他分区的第一个副本放置位置相对于第 0 个分区依次往后移。也就是如果我们有 5 个Broker，5 个分区，假设第一个分区放在第四个 Broker 上，那么第二个分区将会放在第五个 Broker 上；第三个分区将会放在第一个 Broker 上；第四个分区将会放在第二个Broker 上，依次类推；
>  *  剩余的副本相对于第一个副本放置位置其实是由 nextReplicaShift 决定的，而这个数也是随机产生的

### **36、partition 的数据如何保存到硬盘** ###

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

### **37、kafka 的 ack 机制** ###

> request.required.acks 有三个值 0 1 -1
> 
>  *  0:生产者不会等待 broker 的 ack，这个延迟最低但是存储的保证最弱当 server 挂掉的时候，就会丢数据。
>  *  1：服务端会等待 ack 值 leader 副本确认接收到消息后发送 ack 但是如果 leader 挂掉后，他不确保是否复制完成新 leader 也会导致数据丢失。
>  *  \-1：同样在 1 的基础上 服务端会等所有的 follower 的副本受到数据后才会受到 leader 发出的 ack，这样数据不会丢失。

### **38、Kafka 的消费者如何消费数据** ###

> 消费者每次消费数据的时候，消费者都会记录消费的物理偏移量（offset）的位置。等到下次消费时，他会接着上次位置继续消费

### **39、消费者负载均衡策略** ###

> 一个消费者组中的一个分片对应一个消费者成员，他能保证每个消费者成员都能访问，如果组中成员太多会有空闲的成员。

### **40、数据有序** ###

> 一个消费者组里它的内部是有序的
> 
> 消费者组与消费者组之间是无序的

### **41、kafaka 生产数据时数据的分组策略** ###

>  *  生产者决定数据产生到集群的哪个 partition 中
>  *  每一条消息都是以（key，value）格式
>  *  Key 是由生产者发送数据传入，所以生产者（key）决定了数据产生到集群的哪个 partition

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

> 数据传输的事务定义通常有以下三种级别：
> 
> （1）最多一次: 消息不会被重复发送，最多被传输一次，但也有可能一次不传输。
> 
> （2）最少一次: 消息不会被漏发送，最少被传输一次，但也有可能被重复传输。
> 
> （3）精确的一次（Exactly once）: 不会漏传输也不会重复传输,每个消息都传输被一次而且仅仅被传输一次，这是大家所期望的。

### **43、Kafka 判断一个节点是否还活着有那两个条件？** ###

> （1）节点必须可以维护和 ZooKeeper 的连接，Zookeeper 通过心跳机制检查每个节点的连接
> 
> （2）如果节点是个 follower,他必须能及时的同步 leader 的写操作，延时不能太久

### **44、producer 是否直接将数据发送到 broker 的 leader(主节点)？** ###

> producer 直接将数据发送到 broker 的 leader(主节点)，不需要在多个节点进行分发，为了帮助 producer 做到这点，所有的 Kafka 节点都可以及时的告知:哪些节点是活动的，目标topic 目标分区的 leader 在哪。这样 producer 就可以直接将消息发送到目的地了。

### **45、Kafa consumer 是否可以消费指定分区消息？** ###

> Kafa consumer 消费消息时，向 broker 发出"fetch"请求去消费特定分区的消息，consumer指定消息在日志中的偏移量（offset），就可以消费从这个位置开始的消息，customer 拥有了 offset 的控制权，可以向后回滚去重新消费之前的消息。

### 46、Kafka 为什么不支持读写分离? ###

这道题目考察的是你对 Leader/Follower 模型的思考。

> Leader/Follower 模型并没有规定 Follower 副本不可以对外提供读服务。很多框架都是允 许这么做的，只是 Kafka 最初为了避免不一致性的问题，而采用了让 Leader 统一提供服 务的方式。
> 
> 不过，在开始回答这道题时，你可以率先亮出观点:**自 Kafka 2.4 之后，Kafka 提供了有限度的读写分离，也就是说，Follower 副本能够对外提供读服务**。
> 
> 说完这些之后，你可以再给出之前的版本不支持读写分离的理由。
> 
>  *  **场景不适用**。读写分离适用于那种读负载很大，而写操作相对不频繁的场景，可 Kafka 不属于这样的场景。
>  *  **同步机制**。Kafka 采用 PULL 方式实现 Follower 的同步，因此，Follower 与 Leader 存 在不一致性窗口。如果允许读 Follower 副本，就势必要处理消息滞后(Lagging)的问题。

### 47、如何调优 Kafka? ###

回答任何调优问题的第一步，就是**确定优化目标，并且定量给出目标！**这点特别重要。

> 对于 Kafka 而言，常见的优化目标是吞吐量、延时、持久性和可用性。每一个方向的优化思路都 是不同的，甚至是相反的。
> 
> 确定了目标之后，还要明确优化的维度。有些调优属于通用的优化思路，比如对操作系统、 JVM 等的优化;有些则是有针对性的，比如要优化 Kafka 的 TPS。我们需要从 3 个方向去考虑
> 
>  *  **Producer 端**:增加 batch.size、linger.ms，启用压缩，关闭重试等。
>  *  **Broker 端**:增加 num.replica.fetchers，提升 Follower 同步 TPS，避免 Broker Full GC 等。
>  *  **Consumer**:增加 fetch.min.bytes 等

### 48、简述 Follower 副本消息同步的完整流程 ###

> 首先，Follower 发送 FETCH 请求给 Leader。接着，Leader 会读取底层日志文件中的消 息数据，再更新它内存中的 Follower 副本的 LEO 值，更新为 FETCH 请求中的 fetchOffset 值。最后，尝试更新分区高水位值。Follower 接收到 FETCH 响应之后，会把 消息写入到底层日志，接着更新 LEO 和 HW 值。
> 
> Leader 和 Follower 的 HW 值更新时机是不同的，Follower 的 HW 更新永远落后于 Leader 的 HW。这种时间上的错配是造成各种不一致的原因。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70]: /images/20221120/abfd4f4265f94ba59ea0adb33286bbcf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 1]: /images/20221120/73d517bcb13d4096932abef41c019c3d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 2]: /images/20221120/544814233f3c47e4947cb7b09a432a34.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200109151735983.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200109152839311.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20200110083448829.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20200110091218361.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70
[KAFKA-3043]: https://www.iteblog.com/redirect.php?url=aHR0cHM6Ly9pc3N1ZXMuYXBhY2hlLm9yZy9qaXJhL2Jyb3dzZS9LQUZLQS0zMDQz&article=true
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 7]: https://img-blog.csdnimg.cn/20201109143105734.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70
[20201109135248154.png]: https://img-blog.csdnimg.cn/20201109135248154.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 8]: https://img-blog.csdnimg.cn/2020110913530035.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 9]: https://img-blog.csdnimg.cn/20201109135431591.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg_size_16_color_FFFFFF_t_70 10]: https://img-blog.csdnimg.cn/20201109135918700.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoaXBmZWlfY3Nkbg==,size_16,color_FFFFFF,t_70