Kafka面试题

kafka架构描述

kafka分区与副本

分区数并不是越多越好，一般分区数不要超过集群机器数量。分区数越多占用内存越大（ISR等），一个节点集中的分区也就越多，当它宕机的时候，对系统的影响也就越大。

分区数一般设置为：3-10个

一般我们设置成2个或3个，很多企业设置为2个。

kafka数据可靠性

Ack=0，相当于异步发送，消息发送完毕即offset增加，继续生产。

Ack=1，leader收到leader replica 对一个消息的接受ack才增加offset，然后继续生产。

Ack=-1，leader收到所有replica 对一个消息的接受ack才增加offset，然后继续生产。

kafka幂等性

幂等：多次 *** 作的结果和一次 *** 作的结果相同，就称为幂等性 *** 作。读 *** 作一定是幂等性 *** 作，写 ***

作不是幂等性 *** 作。

Kafka的producer和broker之间默认有应答（ack）机制，当kafka的producer发送数据给broker，

如果在规定的时间没有收到应答，生产者会自动重发数据，这样的 *** 作可能造成重复数据（at least

onnce语义）的产生。

enable.idempotence = true //开启幂等性 
properties.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG,true); 

kafka生产者分区策略

分区的原则：
1）指明partition的情况下，直接将指明的值直接作为partition值；
2）没有指明partition值但有key的情况下，将key的hash值与topic的partition数进行取余得到
partition值；
3）没有partition和key情况下，第一次调用时随机生成一个整数，将这个值与topic可用的par
tition总数取余得到partition值，也就是常说的round-robin算法。

kafka消费者分区分配方案

在 Kafka内部存在两种默认的分区分配策略：Range和 RoundRobin。

Range是默认策略。Range是对每个Topic而言的（即一个Topic一个Topic分），首先对同一个Topic里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。然后用Partitions分区的个数除以消费者线程的总数来决定每个消费者线程消费几个分区。如果除不尽，那么前面几个消费者线程将会多消费一个分区。

例如：我们有10个分区，两个消费者（C1，C2），3个消费者线程，10 / 3 = 3而且除不尽。

C1-0 将消费 0, 1, 2, 3 分区

C2-0 将消费 4, 5, 6 分区

C2-1 将消费 7, 8, 9 分区

RoundRobin：前提：同一个Consumer Group里面的所有消费者的num.streams（消费者消费线程数）必须相等；每个消费者订阅的主题必须相同。

第一步：将所有主题分区组成TopicAndPartition列表，然后对TopicAndPartition列表按照hashCode进行排序，最后按照轮询的方式发给每一个消费线程。

kafka中过期数据清理

Kafka将数据持久化到了硬盘上，允许你配置一定的策略对数据清理，清理的策略有两个，删除和压缩。

① 删除

log.cleanup.policy=delete启用删除策略
直接删除，删除后的消息不可恢复。可配置以下两个策略：
清理超过指定时间清理：
log.retention.hours=16
超过指定大小后，删除旧的消息：
log.retention.bytes=1073741824
为了避免在删除时阻塞读 *** 作，采用了copy-on-write形式的实现，删除 *** 作进行时，读取 *** 作的二分查找功能实际是在一个静态的快照副本上进行的，这类似于Java的CopyOnWriteArrayList。

② 压缩

将数据压缩，只保留每个key最后一个版本的数据。
首先在broker的配置中设置log.cleaner.enable=true启用cleaner，这个默认是关闭的。
在topic的配置中设置log.cleanup.policy=compact启用压缩策略。

压缩策略的细节

如上图，在整个数据流中，每个Key都有可能出现多次，压缩时将根据Key将消息聚合，只保留最后一次出现时的数据。这样，无论什么时候消费消息，都能拿到每个Key的最新版本的数据。
压缩后的offset可能是不连续的，比如上图中没有5和7，因为这些offset的消息被merge了，当从这些offset消费消息时，将会拿到比这个offset大的offset对应的消息，比如，当试图获取offset为5的消息时，实际上会拿到offset为6的消息，并从这个位置开始消费。
这种策略只适合特殊场景，比如消息的key是用户ID，消息体是用户的资料，通过这种压缩策略，整个消息集里就保存了所有用户最新的资料。
压缩策略支持删除，当某个Key的最新版本的消息没有内容时，这个Key将被删除，这也符合以上逻辑。

kafka高效读写数据

1、顺序写磁盘

kafka的producer生产的数据时顺序追加到log文件的末端，这样减少了大量的磁头寻址，比随机写要快很多。

2、零拷贝技术

通常情况下，Kafka的消息会有多个订阅者，生产者发布的消息会被不同的消费者多次消费，为了优化这个流程，Kafka使用了“零拷贝技术”

“零拷贝技术”只用将磁盘文件的数据复制到页面缓存中一次，然后将数据从页面缓存直接发送到网络中（发送给不同的订阅者时，都可以使用同一个页面缓存），避免了重复复制 *** 作。

如果有10个消费者，传统方式下，数据复制次数为4*10=40次，而使用“零拷贝技术”只需要1+10=11次，一次为从磁盘复制到页面缓存，10次表示10个消费者各自读取一次页面缓存。

Kafka消费能力不足怎么办

可以从两方面考虑：

1、如果是Kafka消费能力不足，则可以考虑增加Topic的分区数（一般一个Topic分区数为3-10个），并且同时提升消费组的消费者数量，消费者数==分区数。两者缺一不可

2、如果是下游的数据处理不及时：则提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压。

kafka参数调优

buffer.memory

“buffer.memory”的本质就是用来约束KafkaProducer能够使用的内存缓冲的大小的，他的默认值是32MB

batch.size

决定了你的每个Batch要存放多少数据就可以发送出去了，这个参数的默认值是16KB

linger.ms

他的含义就是说一个Batch被创建之后，最多过多久，不管这个Batch有没有写满，都必须发送出去了。

max.request.size

这个参数决定了每次发送给Kafka服务器请求的最大大小，同时也会限制你一条消息的最大大小也不能超过这个参数设置的值

“retries”和“retries.backoff.ms”

决定了重试机制，也就是如果一个请求失败了可以重试几次，每次重试的间隔是多少毫秒。

Kafka消费数据的模式? pull or push

Kafka Consumer采用的是主动拉取broker数据进行消费的。一般消息中间件存在推送(server推送数据给consumer)和拉取(consumer主动取服务器取数据)两种方式，这两种方式各有优劣。

如果是选择推送的方式最大的阻碍就是服务器不清楚consumer的消费速度，如果consumer中执行的 *** 作又是比较耗时的，那么consumer可能会不堪重负,甚至会导致系统挂掉。

而采用拉取的方式则可以解决这种情况，consumer根据自己的状态来拉取数据,可以对服务器的数据进行延迟处理。但是这种方式也有一个劣势就是服务器没有数据的时候可能会一直轮询，不过还好Kafka在poll()有参数允许消费者请求在“长轮询”中阻塞，等待数据到达(并且可选地等待直到给定数量的字节可用以确保传输大小)。

Kafka中的ISR/AR代表什么，ISR伸缩指什么

ISR（In-Sync Replicas），副本同步队列。ISR中包括Leader和Follower。如果Leader进程挂掉，会在ISR队列中选择一个服务作为新的Leader。有replica.lag.max.messages（延迟条数）和replica.lag.time.max.ms（延迟时间）两个参数决定一台服务是否可以加入ISR副本队列，在0.10版本移除了replica.lag.max.messages参数，防止服务频繁的进去队列。

HW、LEO分别代表什么

LEO（LogEndOffffset）：表示每个partition的log最后一条Message的位置。

HW（High Watermark）：表示partition各个replicas数据间同步且一致的offffset位置，即表示

allreplicas已经commit位置，每个Broker缓存中维护此信息，并不断更新。是指consumer能够看

到的此partition位置。 ISR 集合中最小的 LEO 即为分区的 HW

kafka数据量、机器数量、硬盘大小

① 数据量

每天总数据量100g，每天产生1亿条日志， 10000万/24/60/60=1150条/每秒钟

平均每秒钟：1150条

低谷每秒钟：400条

高峰每秒钟：1150条*（2-20倍）=2300条-23000条

每条日志大小：0.5k-2k

每秒多少数据量：2.3M-20MB

② 硬盘大小

每天的数据量*7天

③ 机器数量

机器数量、硬盘大小

① 数据量

每天总数据量100g，每天产生1亿条日志， 10000万/24/60/60=1150条/每秒钟

平均每秒钟：1150条

低谷每秒钟：400条

高峰每秒钟：1150条*（2-20倍）=2300条-23000条

每条日志大小：0.5k-2k

每秒多少数据量：2.3M-20MB

② 硬盘大小

每天的数据量*7天

③ 机器数量

Kafka机器数量=2*（峰值生产速度*副本数/100）+1