Kafka 笔录

Kafka

一、Kafka 概述

1.1 消息队列

​ 1）点对点模式：一对一，消费者主动拉取数据，消息收到后回复收到确认，队列中消息被清除。

​ 2）订阅/发布模式：一对多，数据生产后，推送给所有订阅者，消息会在指定时间后自动清除。

​ Kafka 是基于发布订阅模式的。

1.2 消息队列的主要作用

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

​ 2）异步通信：不必立即处理消息，想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

​ 3）削峰：使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

1.3 Kafka 概述

​ 1）在流式计算中，Kafka 一般用来缓存数据，Storm 通过消费 Kafka 的数据进行计算。

​ 2）Apache Kafka 是一个开源消息系统，由 Scala 编写。

​ 3）Kafka 是一个基于发布订阅模式的分布式消息队列。 Kafka 对消息保存时根据 Topic 进行归类，发送消息者称为 Producer，消息接受者称为 Consumer，此外 Kafka 集群有多个 Kafka 实例组成，每个实例 (server) 称为 broker。

​ 4）无论是 Kafka 集群，还是 Consumer 都依赖于 zookeeper 集群保存一些 meta 信息，来保证系统可用性。

1.4 Kafka 架构

1）Producer ：消息生产者，就是向 kafka broker 发消息的客户端；

2）Consumer ：消息消费者，向 kafka broker 获取消息的客户端；

3）Topic ：可以理解为一个队列，生产者和消费者面向的都是一个topic；

4） Consumer Group （CG）：消费者组，由多个 consumer 组成。**消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个消费者消费；消费者组之间互不影响。**所有的消费者都属于某个消费者组，即 消费者组是逻辑上的一个订阅者。

5）Broker ：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic；

6）Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列。partition 中的每条消息都会被分配一个有序的 id（offset）。kafka 只保证按一个 partition 中的顺序将消息发给 consumer，不保证一个 topic 的整体（多个 partition 间）的顺序；

7）Offset：kafka 的存储文件都是按照 offset.kafka 来命名，用 offset 做名字的好处是方便查找。例如你想找位于 2049 的位置，只要找到 2048.kafka 的文件即可。当然 the first offset 就是 00000000000.kafka。

8）Replication：副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失，且 kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。副本的数量不能大于 broker 的数量，且相同分区的副本会被分配到不同的 broker。

9）leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader。

10）follower：每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 会成为新的 leader。

二、Kafka 集群部署

2.1 环境准备

jar 包下载：http://kafka.apache.org/downloads.html

2.2 Kafka 集群部署

1. 解压安装包

   tar -zxvf kafka_2.11-0.11.0.0.tgz -C /opt/module/
   

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

   mv kafka_2.11-0.11.0.0/ kafka
   

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

   mkdir logs
   

4. 修改配置文件

   cd config/
   vim 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	-- 此处修改
   

5. 配置环境变量

   sudo vim /etc/profile
   #KAFKA_HOME
   export KAFKA_HOME=/opt/module/kafka
   export PATH=$PATH:$KAFKA_HOME/bin
   source /etc/profile
   

6. 分发安装包

   xsync kafka/
   

   注意：分发之后记得配置其他机器的环境变量

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

8. 启动集群

   依次在hadoop102、hadoop103、hadoop104节点上启动kafka

   bin/kafka-server-start.sh config/server.properties
   

9. 关闭集群

   bin/kafka-server-stop.sh stop
   

2.3 Kafka 命令行操作

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

   bin/kafka-topics.sh --zookeeper hadoop102:2181 --list
   

2. 创建 topic

   bin/kafka-topics.sh --zookeeper hadoop102:2181 --create --replication-factor 3 --partitions 1 --topic first
   

   选项说明：

   –topic 定义 topic 名

   –replication-factor 定义副本数

   –partitions 定义分区数

3. 删除 topic

   bin/kafka-topics.sh --zookeeper hadoop102:2181 --delete --topic first
   

   需要 server.properties 中设置 delete.topic.enable=true 否则只是标记删除或者直接重启。

4. 生产者生产消息

   bin/kafka-console-producer.sh --broker-list hadoop102:9092 --topic first
   >maben
   >chengfan
   

5. 消费者消费消息

   bin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --from-beginning --topic first
   

   –from-beginning：会把 first 主题中以往所有的数据都读取出来。根据业务场景选择是否增加该配置。

   –bootstrap-server hadoop102:9092 ：在新版本中 kafka 会建议使用 --bootstrap-server hadoop102:9092 参数来将 offset.kafka 保存到本地，故用可以使用 --bootstrap-server hadoop102:9092 替代 --zookeeper hadoop102:2181，这样也可以省去 kafka 和 zookeeper 之间的通信，提高效率。

6. 查看某个 Topic 的详情

   bin/kafka-topics.sh --zookeeper hadoop102:2181 --describe --topic first
   

7. 修改某个 Topic 的分区数

   bin/kafka-topics.sh --zookeeper hadoop102:2181 --alter --topic first --partitioins 5
   

   分区数只能增大，不能减少，否则之前的分区中的数据将无处安放。

三、Kafka 工作流程分析

3.1 Kafka 工作流程及存储机制

Kafka 中消息是以 topic 进行分类的，生产者生产消息，消费者消费消息，都是面向 topic 的。

topic 是逻辑上的概念，而 partition 是物理上的概念，每个 partition 对应于文件夹，该文件夹的命名规则为：topic名称+分区序号。例如，first 这个 topic 有三个分区，则其对应的文件夹为 first-0, first-1, first-2。该文件夹下的 log 文件中存储的就是 producer 生产的数据。

Producer 生产的数据会被不断追加到该 log 文件末端，且每条数据都有自己的 offset。消费者组中的每个消费者，都会实时记录自己消费到了哪个 offset，以便出错恢复时，从上次的位置继续消费。

​ 由于生产者生产的消息会不断追加到 log 文件末尾，为防止 log 文件过大导致数据定位效率低下，Kafka 采取了 分片 的概念 和 索引 机制，将每个 partition 逻辑上分为多个 segment。每个 segment 对应两个文件——“.index”文件和“.log”文件。

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

​ “.index”文件存储大量的索引信息，“.log”文件存储大量的数据，索引文件中的元数据指向对应数据文件中message 的物理偏移地址。

3.2 Kafka Producer

① Prodeucer 流程

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

② Partition

​ 消息发送时都被发送到一个 topic，其本质就是一个目录，而 topic 是由一些 Partition Logs (分区日志)组成，其组织结构如下图所示：

​ 每个 Partition 中的消息都是有序的，生产的消息被不断追加到 .log 上，其中的每一个消息都被赋予了一个唯一的 offset 值。

​ 分区的原因：

​ （1）方便在集群中扩展，每个 Partition 可以通过调整以适应它所在的机器，而一个 topic 又可以有多个 Partition 组成，因此整个集群就可以适应任意大小的数据了；

​ （2）可以提高并发，因为可以以 Partition 为单位读写了，避免大量 consumer 进入同一个 broker 读取消息。

​ 分区策略：

​ producer 发送的数据封装成一个 ProducerRecord 对象

​ （1）指明 partition 的情况下，直接将指明的值作为 partition 值；
​ （2）未指定 patition 但指定 key 的情况下，默认根据传递消息的 key 来进行分区的分配，即 hash(key) % numPartitions。如果 Key 相同的话，就分配到同一分区。
​ （3）patition 和 key 都未指定，第一次调用时随机生成一个整数，这个整数与可用的 partition 数取余得到 partition 值，后面每次调用在给这个整数自增1，就可以达到轮询 partition 的目的。这也就是常说的轮询调度算法 round-robin（此种算法可以应对负载均衡问题，适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况）。

// DefaultPartitioner类
public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {
        List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);
        int numPartitions = partitions.size();
        if (keyBytes == null) {
            int nextValue = nextValue(topic);
            List<PartitionInfo> availablePartitions = cluster.availablePartitionsForTopic(topic);
            if (availablePartitions.size() > 0) {
                int part = Utils.toPositive(nextValue) % availablePartitions.size();
                return availablePartitions.get(part).partition();
            } else {
                // no partitions are available, give a non-available partition
                return Utils.toPositive(nextValue) % numPartitions;
            }
        } else {
            // hash the keyBytes to choose a partition
            return Utils.toPositive(Utils.murmur2(keyBytes)) % numPartitions;
        }
    }

③ 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 中复制数据，且 leader 与 follower 不会在一个 broker 上，当 leader 所在的 broker 宕机后，follower 将工作。

④ 数据可靠性(ISR、ACK)

​ 为保证 producer 发送的数据，能可靠的发送到指定的 topic，topic 的每个 partition 收到 producer 发送的数据后，都需要向 producer 发送 ack（acknowledgement确认收到），如果 producer 收到 ack，就会进行下一轮的发送，否则重新发送数据。

​ ① 副本同步策略

​ Kafka 为保证数据的可靠性，会等待所有的 follower 全部完成同步，才发送 ack。

​ 但是有一个 follower，因为某种故障，迟迟不能与 leader 进行同步，那 leader 就要一直等下去，直到它完成同步，才能发送 ack。为解决这个问题，Kafka 又采用了 ISR 策略。

​ ② ISR

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

​ ③ ack应答机制

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

​ 1：producer 等待 broker 的 ack，partition 的 leader 落盘成功后返回 ack，如果在 follower 同步成功之前 leader 故障，那么将会 丢失数据；

​ -1（all）：producer 等待 broker 的 ack，partition 的 leader 和 follower 全部落盘成功后才返回 ack。但是如果在 follower 同步完成后，broker 发送 ack 之前，leader 发生故障，那么会选举新的 leader，新的 leader 会再次被收到数据，造成 数据重复。

​ ④ 故障处理细节

​ （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 同步数据。

​ 注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。

⑤ Exactly once 语义

​ 对于某些比较重要的消息，我们需要保证exactly once语义，即 保证每条消息被发送且仅被发送一次。

​ 在0.11版本之后，Kafka Producer 引入了幂等性机制（idempotent），配合 acks = -1 时的 at least once 语义，实现了 producer 到 broker 的 exactly once 语义。

​ idempotent + at least once = exactly once

​ 使用时，只需将 enable.idempotence 属性设置为 true，kafka 自动将 acks 属性设为-1，并将 retries 属性设为 Integer.MAX_VALUE。

​ 补充：Kafka 实现幂等性的原理 https://www.jianshu.com/p/b1599f46229b

3.3 Kafka Consumer

① 消费方式

​ consumer 采用 pull（拉）模式从 broker 中读取数据。

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

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

② 分区分配策略

分区分配策略实际是指 Partition 到 Consumer 的分配策略。

Kafka 有两种分配策略，一是 roundrobin，一是 range。默认采用 range 策略，因为 range 效率略高。

但是 range 策略每次以一个 topic 为单位，进行对不同的 consumer 轮询分配。当 consumer 订阅多个 topic 时，就会导致每次轮询的 不均匀分配现象 放大，最终导致某一个 consumer 的负载过大。

而 roundrobin 是基于所有 topic 的分区来进行分配的，一次将所有的 partition 轮询分配到 consumer 中，这样就避免了不均匀分配的问题。

③ offset 的维护

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

​ Kafka 0.9 版本之前，consumer 默认将 offset 保存在 Zookeeper 中，从0.9版本开始，consumer 默认将 offset 保存在 Kafka 一个内置的 topic 中，该 topic 为 __consumer_offsets。

④ 消费者组案例

​ 需求：测试同一个消费者组中的一个消费者，同一时刻只能消费一个分区的数据。

​ 分别在 hadoop102、hadoop103 上修改 /opt/module/kafka/config/consumer.properties 配置文件中的 group.id 属性为任意组名，确保两个消费者在同一个组。

vim consumer.properties
group.id=maben996

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

[maben996@hadoop102 kafka]$ bin/kafka-console-consumer.sh --zookeeper hadoop102:2181 --topic first --consumer.config config/consumer.properties
[maben996@hadoop103 kafka]$ bin/kafka-console-consumer.sh --zookeeper hadoop102:2181 --topic first --consumer.config config/consumer.properties

​ 在 hadoop104 上启动生产者

bin/kafka-console-producer.sh --broker-list hadoop102:9092 --topic first

​ 查看 hadoop102 和 hadoop103 的接收者。同一时刻只有一个消费者接收到消息。

3.4 Kafka 高效读写数据

​ 1）顺序写磁盘

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

​ 2）零拷贝技术

​ Zero-Copy：指将数据直接从磁盘文件复制到网卡设备中，而不需要经由应用程序之手，减少了内核和用户模式之间的上下文切换，零拷贝技术通过DMA技术实现。

​ Kafka 采用 Zero-Copuy技术将序列化的 .log 文件复制到内核模式下的 Read Cache 中。不过没有数据被复制到 Socket Cache，只有包含数据的位置和长度的信息的文件描述符被加到 Socket Cache 中。DMA 引擎直接将数据从内核模式中传递到网卡设备。这里上下文切换变成了2次,也只经历了2次复制过程就从磁盘中传送出去了。

3.5 Zookeeper 在 Kafka 中的作用

​ Kafka 集群中有一个 broker 会被选举为 Controller，负责 管理集群 broker 的上下线，所有 topic 的 分区副本分配和 leader 选举 等工作。

​ Controller 的管理工作都是依赖于 Zookeeper 的。
1）每台已启动的 broker 都会在 Zookeeper 上进行注册，包括其 isr 的动态数组。

2）每个 broker 中都有一个 Kafka Controller 实例，Controller 实行先到先得的竞争机制，在 Zookeepr 上注册为 Controller Leader，其他 Controller 则会进入监听状态，等待 Controller Leader 下线后，继续竞争 Controller Leader

3）Controller Leader 会监听 Zookeeper 上的节点信息，一旦发生变化，触发监听程序。

4）负责 管理集群 broker 的上下线，所有 topic 的 分区副本分配 和 leader 选举 等工作。

5）以 leader 选举为例，当 Kafka 的 leader 节点下线后，Zookeeper 上更新 ISR 和 ids（下线的 broker 从 ids、ISR中删除 ），Controller 监听节点信息变化后，获取新的 ISR，默认的 leader 选举机制时将 isr 中第一个 broker_id 的节点选取为新的 leader。

四、Kafka API

4.1 Producer API

① 消息发送流程

​ Kafka 的 Producer 发送消息默认采用的是 异步发送 的方式。在消息发送的过程中，涉及到了 两个线程：main线程和Sender线程， 一个线程共享变量：RecordAccumulator，也叫做缓存区，当缓冲区中的消息数量，累积到一定数量时，将消息封装成一个 RecordBatch，统一发送。

RecordBatch，统一发送消息。

​ main 线程将消息发送给 RecordAccumulator，Sender 线程不断从 RecordAccumulator 中拉取消息发送到 Kafka broker。
相关参数：

batch.size：只有数据积累到 batch.size 之后，sender 才会发送数据。

linger.ms：如果数据迟迟未达到 batch.size，sender 等待 linger.time 之后就会发送数据。

② 异步发送 API

导入依赖

<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka-clients</artifactId>
<version>0.11.0.0</version>
</dependency>

编写代码

需要用到的类：

KafkaProducer：需要创建一个生产者对象，用来发送数据

ProducerConfig：获取所需的一系列配置参数

ProducerRecord：每条数据都要封装成一个 ProducerRecord 对象

1.不带回调函数的 API

public class CustomProducer {

    public static void main(String[] args) throws ExecutionException, InterruptedException {

        Properties props = new Properties();
        // 配置 kafka 集群
        props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092,hadoop103:9092");
        // 配置序列化
        props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
        props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
        // ACK 机制参数设置
        props.put(ProducerConfig.ACKS_CONFIG, "-1");
        // 1.创建 KafkaProdeucer 对象
        KafkaProducer<String, String> producer = new KafkaProducer<String, String>(props);
        // 2.调用 send 方法
        for (int i = 0; i < 100; i++) {
            ProducerRecord<String, String> producerRecord =
                    new ProducerRecord<String, String>("first", "message-" + i);
            producer.send(producerRecord);
        }
        // 3.关闭资源
        producer.close();
    }
}

2.带回调函数的 API

​ 回调函数会在 producer 收到 ack 时调用，为异步调用，该方法有两个参数，分别是 RecordMetadata 和 Exception，如果 Exception 为 null，说明消息发送成功，如果 Exception 不为 null，说明消息发送失败。

​ 注意：消息发送失败会自动重试，不需要我们在回调函数中手动重试。

public class CallbackProducer {
    public static void main(String[] args) {
        Properties props = new Properties();
        // 配置 kafka 集群地址，寻找meta
        props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092");
        // 配置序列化
        props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
        props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
        // 配置ack机制参数
        props.put(ProducerConfig.ACKS_CONFIG, "-1");
        // 配置失败重试次数
        props.put(ProducerConfig.RETRIES_CONFIG, 0);
        // 配置单批次数据发送时间阈值
        props.put(ProducerConfig.LINGER_MS_CONFIG, 1);
        // 1.创建 KafkaProdeucer 对象
        KafkaProducer<String, String> producer = new KafkaProducer<String, String>(props);
        // 2.调用 send 方法
        for (int i = 0; i < 10; i++) {
            ProducerRecord<String, String> producerRecord =
                    new ProducerRecord<String, String>("first","message-" + i);
            producer.send(producerRecord, new Callback() {
                public void onCompletion(RecordMetadata recordMetadata, Exception e) {
                    // e == null 说明，发送成功
                    if (e == null) {
                        System.out.println("success:" + recordMetadata.topic() +
                                "-" + recordMetadata.partition() +
                                "-" + recordMetadata.offset());
                    } else {
                        e.printStackTrace();
                    }
                }
            });
        }
        // 3.关闭资源
        producer.close();
    }
}

③ 同步发送 API

​ 同步发送的意思就是，一条消息发送之后，会阻塞当前线程，直至返回 ack。

​ 由于 send 方法返回的是一个 Future 对象，根据 Futrue 对象的特点，我们也可以实现同步发送的效果，只需在调用 Future 对象的 get 方发即可。

不带回调函数的 API

public class CustomProducer {

    public static void main(String[] args) throws ExecutionException, InterruptedException {

        Properties props = new Properties();
        props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092,hadoop103:9092");
        props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
        props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
        props.put(ProducerConfig.ACKS_CONFIG, "-1");
        // 将liger.ms参数设置为1000 ，sender线程会1秒从RecordAccumlator中拿取一条消息发送到Kafka的Topic中
        props.put(ProducerConfig.LINGER_MS_CONFIG, 1000);
        // 1.创建 KafkaProdeucer 对象
        KafkaProducer<String, String> producer = new KafkaProducer<String, String>(props);
        // 2.调用 send 方法
        for (int i = 0; i < 100; i++) {
            ProducerRecord<String, String> producerRecord =
                    new ProducerRecord<String, String>("first", "message-" + i);
            Future<RecordMetadata> send = producer.send(producerRecord);
           //send方法返回一个Future类型的send，send.get()会阻塞线（等待sender线程操作）并返回一个 metadata
            RecordMetadata metadata = send.get();
            if (metadata != null) {
                System.out.println("success:" + metadata.topic() + "-" + metadata.offset());
            }
        }
        // 3.关闭资源
        producer.close();
    }
}

4.2 Consumer API

① 自动提交 offset

1. 导入依赖

   <dependency>
   <groupId>org.apache.kafka</groupId>
   <artifactId>kafka-clients</artifactId>
   <version>0.11.0.0</version>
   </dependency>
   

2. 编写代码

   Kafka 提供了自动提交 offset 的功能。

   自动提交offset的相关参数：

   enable.auto.commit：是否开启自动提交 offset 功能

   auto.commit.interval.ms：自动提交 offset 的时间间隔

   public class CustomConsumer {
   
       public static void main(String[] args) {
           //1. 获取KafkaConsumer对象
           Properties props = new Properties();
           // 指定kafka集群
           props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092,hadoop103:9093");
           // 反序列化 key-value
           props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
           props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
           // 指定消费者所在的组
           props.put(ConsumerConfig.GROUP_ID_CONFIG, "maben");
           // 自动提交 offset, 默认也是 true
           props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, true);
           // 提交时间间隔
           props.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, 1000);
           KafkaConsumer<String, String> consumer = new KafkaConsumer<String, String>(props);
           //2. 订阅 topic
           consumer.subscribe(Arrays.asList("first"));
           //3. 消费
           try {
               while (true) {
                   ConsumerRecords<String, String> records = consumer.poll(100);
                   for (ConsumerRecord<String, String> record : records) {
                       System.out.println("topic:" + record.topic() +
                                           " partition:" + record.partition() +
                                           " offset:" + record.offset() +
                                           " value:" + record.value());
                   }
               }
           } finally {
               //4. 关闭资源
               consumer.close();
           }
       }
   }
   

② 手动提交 offset

自动提交 offset 十分简介便利，但由于其是基于时间提交的，Kafka 还提供了手动提交 offset 的API。

手动提交 offset 的方法有两种：分别是 commitSync（同步提交）和 commitAsync（异步提交）。

两者的不同点：commitSync（同步提交）阻塞当前线程，会自动失败重试，一直到提交成功。commitAsync（异步提交）则没有失败重试机制，故有可能提交失败。

1. 同步提交 offset

   由于同步提交 offset 有失败重试机制，故更加可靠

   public class SyncConsumer {
       public static void main(String[] args) {
           Properties props = new Properties();
           //1. 获取 KafkaConsumer 对象
           props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092,hadoop103:9092");
           // 配置序列化器
           props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
           props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
           // 配合consumergroupID
           props.put(ConsumerConfig.GROUP_ID_CONFIG, "maben");
           // 配置自动提交 offset 默认也是自动提交
           props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, false);
           // 配置 offset 从头开始
           props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
           // 创建 消费者对象
           KafkaConsumer<String, String> consumer = new KafkaConsumer<String, String>(props);
           // 订阅 topic
           consumer.subscribe(Arrays.asList("first"));
           //2. 消费
           try {
               while (true) {
                   ConsumerRecords<String, String> records = consumer.poll(100);
                   for (ConsumerRecord<String, String> record : records) {
                       System.out.println(record.value());
                   }
                   // 同步提交 offsite,当前线程会阻塞知道offset提交成功
                   consumer.commitSync();
               }
           } finally {
               consumer.close();
           }
       }
   }
   

2. 异步提交 offset

   同步提交 offset 会阻塞当前线程，吞吐量会收到很大的影响。因此更多的情况下，会选用异步提交 offset 的方式。

   public class AsyncConsumer {
       public static void main(String[] args) {
           Properties props = new Properties();
           //1. 获取 KafkaConsumer 对象
           props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092,hadoop103:9092");
           props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
           props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
           props.put(ConsumerConfig.GROUP_ID_CONFIG, "maben");
           // 配置自动提交 offsite 默认也是自动提交
           props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, false);
           props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
           KafkaConsumer<String, String> consumer = new KafkaConsumer<String, String>(props);
           consumer.subscribe(Arrays.asList("first"));
           //2. 消费
           try {
               while (true) {
                   ConsumerRecords<String, String> records = consumer.poll(100);
   
                   for (ConsumerRecord<String, String> record : records) {
                       System.out.println(record.value());
                   }
                   // 异步提交 offsite
                   consumer.commitAsync();
               }
           } finally {
               consumer.close();
           }
       }
   }
   

③ 自定义存储 offset

​ Offset 的维护是相当繁琐的，因为需要考虑到消费者的 Rebalance。

​ 当有新的消费者加入消费者组、已有的消费者退出消费者组或者所订阅的 topic 的分区发生变化，就会触发到分区的重新分配，重新分配的过程叫做 Rebalance。

​ 消费者发生 Rebalance 之后，每个消费者消费的分区就会发生变化。因此消费者要首先获取到自己被重新分配到的分区，并且定位到每个分区最近提交的 offset 位置继续消费。

​ 要实现自定义存储 offset，需要借助 ConsumerRebalanceListener，以下为示例代码，其中提交和获取 offset 的方法，需要根据所选的 offset 存储系统自行实现。

public class CustomOffsetConsuemr {
    private static HashMap<TopicPartition, Long> currentOffsets = new HashMap<TopicPartition, Long>();
    public static void main(String[] args) {
        Properties props = new Properties();
        props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092,hadoop103:9092");
        props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
        props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
        props.put(ConsumerConfig.GROUP_ID_CONFIG, "maben996");
        props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
        props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, false);
        KafkaConsumer<String, String> consumer = new KafkaConsumer<String, String>(props);
        consumer.subscribe(Arrays.asList("first"), new ConsumerRebalanceListener() {
            // 该方法会在Rebalance之前调用
            public void onPartitionsRevoked(Collection<TopicPartition> partitions) {
            }
            // 该方法会在Rebalance之后调用
            public void onPartitionsAssigned(Collection<TopicPartition> partitions) {
                currentOffsets.clear();
                for (TopicPartition partition : partitions) {
                    Long offset = getOffsetByTopicPartition(partition);
                    consumer.seek(partition, offset);   // 定位到最近提交的offset的位置继续消费
                }
            }
        });
        try {
            while (true) {
                ConsumerRecords<String, String> records = consumer.poll(100);
                //tx.begin
                for (ConsumerRecord<String, String> record : records) {
                    System.out.println(record.value());
                    currentOffsets.put(new TopicPartition(record.topic(), record.partition()), record.offset());
                }
                commitOffset(currentOffsets);
                //tx.commiit
            }
        } finally {
            consumer.close();
        }
    }
    //提交该消费者所有分区的offset
    private static void commitOffset(HashMap<TopicPartition, Long> currentOffsets) {

    }
    //获取某分区的最新offset
    private static Long getOffsetByTopicPartition(TopicPartition partition) {
        return null;
    }
}

4.3 自定义 Interceptor

① 拦截器原理

​ 对于 producer 而言，interceptor 使得用户在消息发送前以及 producer 回调逻辑前有机会对消息做一些定制化需求，比如修改消息等。producer 允许用户指定多个 interceptor 按序作用于同一条消息从而形成一个拦截链 (interceptor chain)。Intercetpor 的实现接口是 org.apache.kafka.clients.producer.ProducerInterceptor。

（1）configure(configs)：获取配置信息和初始化数据时调用。

（2）onSend(ProducerRecord)：该方法封装进 KafkaProducer.send 方法中，即它运行在用户主线程中。Producer 确保在消息被序列化以及计算分区前调用该方法。用户可以在该方法中对消息做任何操作，但最好保证不要修改消息所属的 topic 和分区，否则会影响目标分区的计算。

（3）onAcknowledgement(RecordMetadata, Exception)：该方法会在消息从 RecordAccumulator 成功发送到 Kafka Broker 之后，或者在发送过程中失败时调用。并且通常都是在 producer 回调逻辑触发之前。 onAcknowledgement 运行在 producer 的 IO 线程中，因此不要在该方法中放入很重的逻辑，否则会拖慢 producer 的消息发送效率。

（4）close：关闭 interceptor，主要用于执行一些资源清理工作。如前所述，interceptor 可能被运行在多个线程中，因此在具体实现时用户需要自行确保线程安全。另外倘若指定了多个 interceptor，则 producer 将按照指定顺序调用它们，并仅仅是捕获每个 interceptor 可能抛出的异常记录到错误日志中而非再向上传递。在使用过程中要特别留意。

② 拦截器案例

需求：实现一个简单的拦截器链。第一个 interceptor 会在消息发送前将时间戳信息加到消息 value 的最前部；第二个 interceptor 会在消息发送后更新成功发送消息数或失败发送消息数。

1. 增加时间的拦截器

   public class TimeInterceptor implements ProducerInterceptor<String, String> {
   
       public ProducerRecord onSend(ProducerRecord record) {
           // 返回一个新的 ProducerRecord，把时间戳写入消息体的最前部
           return new ProducerRecord(record.topic(), record.partition(), record.key(),
                   System.currentTimeMillis()+","+record.value(),record.headers());
       }
       public void onAcknowledgement(RecordMetadata recordMetadata, Exception e) {
   
       }
       public void close() {
   
       }
       public void configure(Map<String, ?> map) {
   
       }
   }
   

2. 统计发送消息成功和发送失败消息数，并在 producer 关闭时打印这两个计数器

   public class CountInterceptor implements ProducerInterceptor<String,String> {
   
       private Long successCount= 0L;
       private Long errorCount = 0L;
       public ProducerRecord<String, String> onSend(ProducerRecord<String, String> producerRecord) {
           return producerRecord;
       }
   
       public void onAcknowledgement(RecordMetadata recordMetadata, Exception e) {
           // 统计失败和成功的次数
           if (e == null) {
               successCount++;
           } else {
               errorCount++;
           }
       }
   
       public void close() {
           // 保存结果
           System.out.println("successCount = " + successCount);
           System.out.println("errorCount = " + errorCount);
       }
   
       public void configure(Map<String, ?> map) {
   
       }
   }
   
   

3. interceptorProducer

   public class InterceptorProducer {
           public static void main(String[] args) throws ExecutionException, InterruptedException {
               // 1.设置配置信息
               Properties props = new Properties();
               // 配置kafka集群地址
               props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "hadoop102:9092,hadoop103:9092");
               // 配置序列化器
               props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
               props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
               // 配置 ack 机制参数
               props.put(ProducerConfig.ACKS_CONFIG, "-1");
               // 配置单批次发送消息的时间阈值
               props.put(ProducerConfig.LINGER_MS_CONFIG, 100);
               // 2.构建拦截链
               List<String> interceptors = new ArrayList<String>();
               interceptors.add("com.atguigu.kafka.interceptor.TimeInterceptor");
               interceptors.add("com.atguigu.kafka.interceptor.CountInterceptor");
               // 封装到配置文件
               props.put(ProducerConfig.INTERCEPTOR_CLASSES_CONFIG, interceptors);
               // 3.创建 KafkaProducer 对象
               KafkaProducer<String, String> producer = new KafkaProducer<String, String>(props);
               // 4.发送消息
               for (int i = 0; i < 100; i++) {
                   ProducerRecord<String, String> record =
                           new ProducerRecord<String, String>("first", " message-" + i);
                   producer.send(record);
               }
            // 5.关闭资源,内部调用interceptor的close方法
               producer.close();
           }
   }
   
   

   测试：在 kafka 上启动消费者，然后运行客户端 java 程序。

五、 Flume 对接 Kafka

需求：监听 44444 端口，将其内容以字母和数字分开，输出到 Kafka 不同的 topic 中

5.1 配置 flume-kafka.conf

# Name the components on this agent
a1.sources = r1
a1.sinks = k1
a1.channels = c1

# Describe/configure the source
a1.sources.r1.type = netcat
a1.sources.r1.bind = hadoop102
a1.sources.r1.port = 44444

# 配置 Interceptor
a1.sources.r1.interceptors = i1
a1.sources.r1.interceptors.i1.type = com.atguigu.flume.CustomInterceptor$Builder

# sinks
a1.sinks.k1.type = org.apache.flume.sink.kafka.KafkaSink
# If the event header contains a “topic” field, the event will be published to that topic overriding the topic configured here.
a1.sinks.k1.kafka.topic = mytopic
a1.sinks.k1.kafka.bootstrap.servers = hadoop102:9092
a1.sinks.k1.kafka.producer.acks = -1
a1.sinks.k1.kafka.producer.linger.ms = 1

#channel
a1.channels.c1.type = memory
a1.channels.c1.capacity = 1000
a1.channels.c1.transactionCapacity = 100

#bind
a1.sources.r1.channels = c1
a1.sinks.k1.channel = c1

5.2 编写拦截器

kafka sink 指定的默认topic = mytopic 会被订阅，a1.sinks.k1.kafka.topic = mytopic

重点：将 event 的 header 设置为 “topic”，value 设置为对应的 topic 值，在数据进入 kafka 时默认订阅的 mytopic 会被 value 的值覆盖

If the event header contains a “topic” field, the event will be published to that topic overriding the topic configured here.

public class CustomInterceptor implements Interceptor {
	@Override
	public void initialize() {
	}
	@Override
	public Event intercept(Event event) {
		byte[] body = event.getBody();
		if (body[0] <= 'z' && body[0] >= 'a') {
			event.getHeaders().put("topic", "letter");
		} else if (body[0] <= '9' && body[0] >= '0') {
			event.getHeaders().put("topic", "number");
		}
		return event;
	}
	@Override
	public List<Event> intercept(List<Event> events) {
		for (Event event : events) {
			intercept(event);
		}
		return events;
	}
	@Override
	public void close() {
	}
	public static class Builder implements Interceptor.Builder {
		@Override
		public void configure(Context context) {
		}
		@Override
		public Interceptor build() {
			return new CustomInterceptor();
		}
	}
}

打包完成，放入到 flume 的 lib 目录下

开启 flume

bin/flume-ng agent -c conf/ -n a1 -f jobs/flume-kafka.conf

开启 zookeeper 集群、kafka 集群，再开启两个 kafka 消费者

bin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --topic number
bin/kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --topic letter

向 44444 端口发送数据

nc hadoop102 44444

六、Kafka 监控

6.1 Kafka Monitor

​ 下载：https://github.com/quantifind/KafkaOffsetMonitor

​ 启动 Zookeeper、Kafka 集群

1. 上传 jar 包 KafkaOffsetMonitor-assembly-0.4.6.jar 到集群

2. 在 /opt/module/ 下创建 kafka-offset-console 文件夹

3. 将上传的 jar 包放入刚创建的目录下

4. 在 /opt/module/kafka-offset-console 目录下创建启动脚本 start.sh，内容如下

   #!/bin/bash
   java -cp KafkaOffsetMonitor-assembly-0.4.6-SNAPSHOT.jar \
   com.quantifind.kafka.offsetapp.OffsetGetterWeb \
   --offsetStorage kafka \
   --kafkaBrokers hadoop102:9092,hadoop103:9092,hadoop104:9092 \
   --kafkaSecurityProtocol PLAINTEXT \
   --zk hadoop102:2181,hadoop103:2181,hadoop104:2181 \
   --port 8086 \
   --refresh 10.seconds \
   --retain 2.days \
   --dbName offsetapp_kafka &
   
   

5. 在 /opt/module/kafka-offset-console 目录下创建 mobile-logs 文件夹

6. 启动 KafkaMonitor

   ./start.sh
   
   

7. 登录页面 hadoop102:8086 端口查看详情

6.2 Kafka Manager

​ 下载：https://github.com/yahoo/kafka-manager/releases

​ 启动：Zookeeper、Kafka 集群

1. 上传压缩包 kafka-manager-1.3.3.15.zip 到集群

2. 解压到 /opt/module

3. 修改配置文件 conf/application.conf

   kafka-manager.zkhosts="hadoop102:2181,hadoop103:2181,hadoop104:2181"
   
   

4. 启动 kafka-manager

   bin/kafka-manager
   
   

5. 登录 hadoop102:9000 页面查看详细信息

6. 添加集群信息
   

7. 查看 Topic 详情
   案例1：处理数据倾斜问题

8. 观察是否有倾斜的情况，如有倾斜，点击 Topic 名称进入
   

9. 查看 Topic 倾斜详情，如有倾斜，可以点击 Preferred Replica Election，重新进行 leader 选举
   

10. 重新进行 leader 选举

11. 等待一会儿，重新选举完成后，数据倾斜消失
    
    案例2：对某一个 Topic 重新分配分区

12. 自动生成分区计划
    

13. 执行分区计划
    

14. 手动配置分区计划
    
    
    ​ 注意：手动配置分区计划时，不能将同一个分区的副本全部放在同一个节点上。

案例3：查看 broker 运作信息

案例4：查看消费者消费信息

七、常见问题

1. Kafka中的 ISR、AR 又代表什么？

   AR = ISR + OSR。

   AR：分区的所有副本

   ISR：与 leader 保持同步的 follower 集合，其中包含 leader。

   OSR：副本同步速度慢于 replica.lag.time.max.ms 指定的阈值，则被踢出ISR存入OSR。

2. Kafka 中的 HW、LEO 等分别代表什么？

   LEO：每个副本的最新消息的 offset

   HW：一个分区中所有副本中最小的 LEO

3. Kafka 中是怎么体现消息顺序性的？

   每个分区内，每条消息都有一个 offset，故只能保证分区内有序。

4. Kafka 中的拦截器、序列化器、分区器是否了解？它们之间的处理顺序是什么？

   interceptor 使得用户在消息发送前以及 producer 回调逻辑前有机会对消息做一些定制化需求，比如修改消息等。

   producer 端需要序列化，consumer 端需要反序列化， Kafka 的 serialization 下提供了很多常用的序列化器，使用时根据反射获取即可，当然也可以自定义序列化器。

   partitionor 默认根据传递消息的 key 来进行分区的分配，即 hash(key) % numPartitions。如果 Key 相同的话，就分配到同一分区。如果没有指定 partition 和 key，partitionor 会采用 round-robin 轮询调度算法，来进行分区。

   拦截器，序列化器，分区器的执行顺序：拦截器 -> 序列化器 -> 分区器

5. Kafka 生产者客户端的整体结构是什么样子的？使用了几个线程来处理？分别是什么？

   Producer 端使用了两个线程和一个共享变量 RecordAccumulator ，一个是 mian 线程，其中先后调用拦截器、序列化器、分区器对消息进行处理，最终将消息分区放入 RecordAccumulator 中；另一个线程是 sender，当 RecordAccumulator 中的数据积攒成为一个 RecordBatch 时，sender 线程负责从 RecordAccumulator 中拉取数据，并发送到 Kafka broker。

6. “消费组中的消费者个数如果超过 topic 的分区，那么就会有消费者消费不到数据”这句话是否正确？

   正确

7. 消费者提交 offset 时提交的是当前消费到的最新消息的 offset 还是 offset+1？

   offset+1

8. 有哪些情形会造成重复消费？

   1）Producer 端，ACK 配置为 -1，broker 会等待 leader 和 follower 全部落盘才返回 ack。但是如果在 follower 落盘后，broker 发送 ack 之前，leader 发生故障，会重新竞选 leader，那么新的 leader 竞选成功后，由于 Producer 端未收到 ack，则会重发之前的数据，后续会造成数据重复，最终会造成重复消费。

   ​ 解决：配置参数enable.idempotence=true，开启幂等性，kafka 会判断重发的数据是否已经被保存过了，如果保存过了，就不会再保存。

   2）Consumer 端，根本原因：已经消费了，但是 offset 没提交，并且无论是同步还是异步提交 offset，都有可能导致重复消费。

   ​ 消费者的消费能力较低，poll 的时间间隔超过了 session.timeout.ms 的时间 ，未提交 offset，coordinator 判断该消费者挂掉，触发 Rebalance，当前 partition 被分配给其他消费者，新的消费者会重复消费之前的数据。

   ​ 解决：让消费者使用阻塞线程，并手动提交 offset。

9. 那些情景会造成消息漏消费？

   1）Producer 端

   1. 同步模式下，ack 机制参数，配置=1 （只有Leader收到，-1 所有副本成功，0 不等待）Leader Partition挂了，数据就会丢失。

   ​ 解决：设置 -1 保证produce 写入所有副本算成功 producer.type = sync request.required.acks=-1

   2. 异步模式下，当缓冲区满了，如果配置为0（没有收到确认，一满就丢弃），数据立刻丢弃。

   ​ 解决：不限制阻塞超时时间。就是一满生产者就阻塞。

   2）Consumer 端，根本原因：先提交offset，消费时出现故障，有可能造成数据的漏消费。

   ​ 在获取 kafka 的消息后正准备入库（未入库），但是消费者挂了，那么如果让 kafka 自动去维护 offset ，它就会认为这条数据已经被消费了，那么会造成数据丢失。

   ​ 解决：使用 kafka 高级API，手动维护偏移量，当数据入库之后进行偏移量的更新。

10. 当你使用 kafka-topics.sh 创建（删除）了一个 topic 之后，Kafka 背后会执行什么逻辑？

    1）会在 zookeeper 中的 /brokers/topics 节点下注册/删除一个新的 topic 节点，如：/brokers/topics/first

    2）zookeeper 节点的变动触发 Controller 的监听程序

    3）kafka Controller 执行topic 的创建工作，并更新 metadata cache

11. topic的分区数可不可以增加？如果可以怎么增加？如果不可以，那又是为什么？

    可以增加

    bin/kafka-topics.sh --zookeeper localhost:2181/kafka --alter --topic topic-config --partitions 3
    
    

12. topic 的分区数可不可以减少？如果可以怎么减少？如果不可以，那又是为什么？

    不可以减少，被删除的分区数据难以处理。

13. Kafka 有内部的 topic 吗？如果有是什么？有什么所用？

    __consumer_offsets，保存消费者 offset

14. Kafka分区分配的概念？

    一个 topic 多个分区，一个消费者组多个消费者，将多个分区分配给多个消费者的策略称为分区分配策略，常见的分区分配策略有两种：roundrobin、range，Kafka 默认使用 range 策略。

15. 简述 Kafka 的日志目录结构？

    每个分区对应一个文件夹，文件夹的命名为 topic-0，topic-1，内部为.log和.index文件。

16. 如果我指定了一个offset，Kafka Controller 怎么查找到对应的消息？

    offset 根据 start_offset.index 文件的名来确定该 offset 在哪个 index 文件（Segment）中，每个 index 文件中的 行号从 1 开始，offset 减去 start_offset 的值，就是 index 文件的行号的，当前行号对应的值就是，该 offset 在 .log 对应的数据的物理存储位置。
    

17. 聊一聊 Kafka Controller 的作用？

    1. 管理集群 broker 的上下线；
    2. 负责 topic 的分区、副本分配；
    3. 负责 leader 选举等工作。

18. Kafka 中有那些地方需要选举？这些地方的选举策略又有哪些？

    Partition Leader（ISR），Controller Leader（先到先得）

19. 失效副本是指什么？有那些应对措施？

    不能及时与 leader 同步的副本会被暂时踢出 ISR，进入 OSR，等其恢复后，会继续写入 offset，直到追上 leader 的 offset 值之后，该副本就会重新加入 ISR。

20. Kafka 的那些设计让它有如此高的性能？

    Kafka 分区方便了集群扩展，同时提高了并发性。

    Kafka producer 生产数据时顺序写入磁盘，提高了吞吐率。

    Kafka 采用的 Zero-Copy 技术，减少数据 copy 次数，提高了传输速率。

21. 如何保证 Kafka 的数据的精确一致性？

    1.在 producer 过程中，要开启幂等性参数，此时会自动将 ack 的参数配置为 -1，并且将重试次数 retries 属性设置为 Integer.MAX_LAUE。

    2.在 consumer 过程中，将 consumer.poll() 消费者拉取数据 和 consumer.commit() 消费者提交 offset 封装在支持事务的数据存储系统中，保证两者的执行具有原子性。或者将消息的唯一标识保存到外部介质中，每次消费时判断是否处理过即可。