Kafka所有重要知识点

一、Kafka的基本架构

Kafka是一个分布式的基于发布/订阅模式的消息队列，

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

二、Kafka深入

1、Kafka的工作流程与文件存储机制

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

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

一个Topic可以分为多个Partition分布在不同的Broker上，每一个Partition都对应一个log文件，生产者生产的文件会不断的追加到文件末尾，导致log文件越来越大，Kafka采取了分片和索引机制，将每个partition分为多个segment。每个segment对应两个文件——“.index”文件和“.log”文件。“.index”文件存储大量的索引信息，“.log”文件存储大量的数据，索引文件中的元数据指向对应数据文件中message的物理偏移地址。

2、Kafka生产者

​ Kafka的Producer发送消息采用的是异步发送的方式。在消息发送的过程中，涉及到了两个线程——main线程和Sender线程，以及一个线程共享变量——RecordAccumulator。main线程将消息发送给RecordAccumulator，Sender线程不断从RecordAccumulator中拉取消息发送到Kafka broker。

2.1分区

（1）分区的原因 ： ① 方便在集群中扩展 ② 可以提高并发

（2）分区的原则：我们需要将producer发送的数据封装成一个ProducerRecord对象。

​ ①指明 partition 的情况下，直接将指明的值直接作为 partiton 值；

​ ②没有指明 partition值但有 key 的情况下，将 key 的 hash 值与 topic 的 partition 数进行取余得到 partition 值；

​ ③既没有 partition 值又没有 key 值的情况下，第一次调用时随机生成一个整数（后面每次调用在这个整数上自增），将这个值与 topic 可用的 partition 总数取余得到 partition 值，以后的消息如果和这个消息处于同一个batch，则和它是同一个分区，否则会轮询分区。在长时间尺度上尽量保证均衡。

2.2数据可靠性保证

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

那么何时发送ACK呢？多少个follower同步leader之后发送ACK呢？

​ Kafka采用了当全部的follower同步完成leader之后，在进行ACK 的发送。但是假如某一个follower迟迟没有完成数据的同步，那么leader就会一直等待。为了解决这样的情况，Leader维护了一个ISR，就是能够和leader同步的follower。若follower在一定的时间阈值（replica.lag.time.max.ms）之后，仍然没有完成与leader 的同步，则此follower会被踢出ISR。

ACK的应答机制：

ACK=0：Producer不等待broker的ACK，一直在发送数据，效率较高，但是可能会丢失数据。

ACK=1：Producer会等待broker的ACK，当Partition中的leader完成数据的落盘后，返回ACK。若follower在同步完成之前leader故障，会造成数据的丢失。

ACK=-1（ALL）：Producer会等待ACK，当Partition中的follower完成数据的同步之后，返回ACK。效率最低，安全性最高。但是如果在follower同步完成后，broker发送ack之前，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同步数据。

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

2.3Exactly Once含义

​ 对于一些非常重要的信息，比如说交易数据，下游数据消费者要求数据既不重复也不丢失，即Exactly Once语义。

​ 0.11版本的Kafka，引入了一项重大特性：幂等性。所谓的幂等性就是指Producer不论向Server发送多少次重复数据，Server端都只会持久化一条。幂等性结合At Least Once（ACK=-1）语义，就构成了Kafka的Exactly Once语义。

​ Kafka的幂等性实现其实就是将原来下游需要做的去重放在了数据上游。开启幂等性的Producer在初始化的时候会被分配一个PID，发往同一Partition的消息会附带Sequence Number。而Broker端会对<PID, Partition, SeqNumber>做缓存，当具有相同主键的消息提交时，Broker只会持久化一条。

3、Kafka消费者

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

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

3.1分区分配策略

​ 一个consumer group中有多个consumer，一个 topic有多个partition，所以必然会涉及到partition的分配问题，即确定那个partition由哪个consumer来消费。

​ Kafka有两种分配策略，一是roundrobin，一是range。

​ roundrobin：采用轮询的方式，依次的将多个Partition分配至不同的Consumer Group。此时若增加新的Partition，则改动较大，因为需要再次重新轮询分配Partition。

​ range：将Partition的前几个分配至第一个Consumer Group，紧接着的几个分配至下一个Consumer Group，重复直至分配完成。

3.2offset的维护

​ consumer需要实时的记录自己消费到哪个offset，以便故障后继续消费。

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

3.3Kafka高效读写数据

（1）顺序写磁盘

Producer生产的数据会依次追加到log文件，为顺序写，速度快。

（2）应用Pagecache

Kafka数据持久化是直接持久化到Pagecache中，这样会产生以下几个好处：

Ø I/O Scheduler 会将连续的小块写组装成大块的物理写从而提高性能

Ø I/O Scheduler 会尝试将一些写操作重新按顺序排好，从而减少磁盘头的移动时间

Ø 充分利用所有空闲内存（非 JVM 内存）。如果使用应用层 Cache（即 JVM 堆内存），会增加 GC 负担

Ø 读操作可直接在 Page Cache 内进行。如果消费和生产速度相当，甚至不需要通过物理磁盘（直接通过 Page Cache）交换数据

Ø 如果进程重启，JVM 内的 Cache 会失效，但 Page Cache 仍然可用

三、一些面试题

1、消费者提交消费位移时提交的是当前消费到的最新消息的offset还是offset+1？ ----->offset+1

2、当你使用kafka-topics.sh创建（删除）了一个topic之后，Kafka背后会执行什么逻辑？
1）会在zookeeper中的/brokers/topics节点下创建一个新的topic节点，如：/brokers/topics/first
2）触发Controller的监听程序
3）kafka Controller 负责topic的创建工作，并更新metadata cache

3、Partition的分区数只能增加，不能减少

4、说一下kafka的优势

高吞吐量：Kafka 每秒可以生产约 25 万消息（50 MB），每秒处理 55 万消息（110 MB）

持久化数据存储：可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如 ETL，以及实时应用程序。通过将数据持久化到硬盘以及replication 防止数据丢失。
分布式系统易于扩展：所有的 producer、broker 和 consumer 都会有多个，均为分布式的。无需停机即可扩展机器。
客户端状态维护：消息被处理的状态是在 consumer 端维护，而不是由 server 端维护。当失败时能自动平衡。

5、为什么大数据环境下的消息队列常选择kafka？

分布式存储数据，提供了更好的性能 可靠性 可扩展能力
利用磁盘存储数据，且按照主题、分区来分布式存放数据，持久化存储，提供海量数据存储能力
采用磁盘存储数据，连续进行读写保证性能，性能和磁盘的性能相关和数据量的大小无关

6、为什么Kafka的吞吐量高，速度快？？

①顺序读写：Kafka的message是不断追加到本地磁盘文件末尾的，而不是随机的写入，这使得Kafka写入吞吐量得到了显著提升 。

②Page Cache：为了优化读写性能，Kafka利用了操作系统本身的Page Cache，就是利用操作系统自身的内存而不是JVM空间内存。这样做的好处有：

1避免Object消耗：如果是使用 Java 堆，Java对象的内存消耗比较大，通常是所存储数据的两倍甚至更多。

2避免GC问题：随着JVM中数据不断增多，垃圾回收将会变得复杂与缓慢，使用系统缓存就不会存在GC问题。

通过操作系统的Page Cache，Kafka的读写操作基本上是基于内存的，读写速度得到了极大的提升。

**③零拷贝：**通过这种 “零拷贝” 的机制，Page Cache 结合 sendfile 方法，Kafka消费端的性能也大幅提升。这也是为什么有时候消费端在不断消费数据时，我们并没有看到磁盘io比较高，此刻正是操作系统缓存在提供数据。

④分区分段+索引：Kafka的message消息实际上是分布式存储在一个一个小的segment中的，每次文件操作也是直接操作的segment。为了进一步的查询优化，Kafka又默认为分段后的数据文件建立了索引文件，就是文件系统上的.index文件。这种分区分段+索引的设计，不仅提升了数据读取的效率，同时也提高了数据操作的并行度。

**⑤批量读写：**在向Kafka写入数据时，可以启用批次写入，这样可以避免在网络上频繁传输单个消息带来的延迟和带宽开销。

**⑥批量压缩：**它把所有的消息都变成一个批量的文件，并且进行合理的批量压缩，减少网络IO损耗。

7、Kafka如何实现幂等性？

​ Kafka的幂等性实现其实就是将原来下游需要做的去重放在了数据上游。开启幂等性的Producer在初始化的时候会被分配一个PID，发往同一Partition的消息会附带Sequence Number。而Broker端会对<PID, Partition, SeqNumber>做缓存，当具有相同主键的消息提交时，Broker只会持久化一条。

​ 但是PID重启就会发生变化，所以不能保证跨分区跨会话的Exactly Once。

​ 为了实现跨分区跨会话的事务，需要引入一个全局唯一的Transaction ID，并将Producer获得的PID和Transaction ID绑定。这样当Producer重启后就可以通过正在进行的Transaction ID获得原来的PID。

​ 为了管理Transaction，Kafka引入了一个新的组件Transaction Coordinator。Producer就是通过和Transaction Coordinator交互获得Transaction ID对应的任务状态。Transaction Coordinator还负责将事务所有写入Kafka的一个内部Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。

on Coordinator。Producer就是通过和Transaction Coordinator交互获得Transaction ID对应的任务状态。Transaction Coordinator还负责将事务所有写入Kafka的一个内部Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。