【随笔记】kafka 基础面试笔记

Myth丶恋晨 2022-10-20 13:43 133阅读 0赞

> 水滴石穿，点滴积累，活到老学到老。

### kafka是什么？ ###

是什么？简单说个人理解就是类似MQ的东西，在分布式发布-消息订阅中处理的很好；上手程度如果使用过任何一种MQ，kafka基本无脑上手。

### kafka的使用场景 ###

*  异步通信：分布式架构的典型特点，消息流转不在是同步等待，那么异步的消息队列处理机制就是基本功能，用户把一个消息放到队列中，消费者可以不立刻处理他，生产者也可以去做其他的事，不在占用线程去原地等待结果。
 *  健壮性：kafka类比其他MQ产品的特点，就是比较抗消息堆积，生产者正常生产，消费者全部挂了，也能在一定时间内正常进行业务（如果一直不恢复，也会挂）。
 *  消费方式：可以一对多，生产一个消息，被多个topic订阅。、
 *  缓冲、削峰：生产侧突发海量流量，消费侧可能抵抗不住，有kafka可以起到缓冲。

### 分布式的kafka ###

小卡的分布式可以使用zookeeper进行协调，这个过程持续了很久，新版本中可以使用内部的group coordination协议，减少zookeeper依赖。不过broker依然依赖zk，选举和检查离不开zk；

### broker ###

消息代理，生产者往这个代理里面的指定topic中写消息，消费者在从broker中自己订阅的topic读消息，相当于商家发货，快递中转，买家收货，broker相当于中转站。

### follower与leader ###

小卡的复制机制不算单纯，属于不完全同步+不完全异步=取长补短；完全同步要求所有的follower都复制完，这条消息才可以commit，这种对于高并发高吞吐量造成的障碍。异步下follower异步从leader中复制数据，数据只要被leader写入log中，就可以认为是commit了，如果leader挂了，数据就没了。

在这种情况小卡使用ISR的方式，follower可以批量的从leader复制数据，而leader利用磁盘顺序读以及send file机制，保证高复制性，从而减小消费丢失产生的消息差。

这里又引入了一个概念 ISR、AR：

*  ISR：副本同步队列。它由leader维护，维护一个与自身保持一致的replica集合，小卡要保证数据不丢失，就要保证ISR中至少有一个数据，并提交消息成功；producer发送数据后，收到的ACK有三种：
    
     *  ACK=1：producer将数据发送出去，经过leader成功接收消息，这个就算发送成功了，如果leader挂了，这个消息就没有了；
     *  ACK=0：producer生产消息后就不需要关注了，也不去管是不是收到，极致的高效率，极致的低可靠；
     *  ACK=-1：这个就是上面说的ISR，等到follower都确认收到了，才算数可靠性极高。当所有的ISR中的Replica都想leader发送ack，leader才提交commit，这时候生产者会才可以认为消息提交了；
 *  AR：所有副本

### kafka快的原因 ###

*  批量处理：合并小请求，以流的方式交互；
 *  零拷贝技术，减少拷贝次数；
 *  顺序写：顺序写在现代操作系统的预读和写技术中，可以做到比随机写快；
 *  缓存：Cache Filesystem Cache PageCache缓存；
 *  上拉模式：上拉模式进行消息消费；

### 生产者优化 ###

*  增加生产者线程
 *  提高批量batch.size
 *  粗暴的增加更多的producer实例
 *  增加partition数
 *  设置acks=-1时，如果延迟增大，增加num.replica.fetchers foolower同步数据线程数
 *  夸数据中心传输增加socket缓冲区及操作系统的TCP缓冲区

### unclean配置 ###

unclean.leader.election.enable=true时就意味着非ISR集合的broker也能参加选举，这要就有可能会丢失数据。spark streaming在消费过程中拿到的end offset会突然变小，会导致spark streaming job挂掉。造成数据不一致可靠性降低了，反之可用性就降低，也是典型的高可用性，高一致性选择题。

### kafka的消息格式 ###

message是由一个固定长度的header和变长的body组成；

### 消息丢失&重复消费 ###

这两点是日常使用的重点：

*  消息发送的两种方式：sync and async；默认是sync方式，也可以通过producer.type进行更改。kafka是通过配置request.required.acks来确定消息的生产的，上面也说了有三种ack，分别是-1、0、1三个。
    
     *  如果acks=0，不和kafka集群进行消息确认，这种情况就容易发生消息丢失，例如网络闪断，缓冲区满了，等等；
     *  如果acks=1，这种是sync情况，要是leader确认接收后挂了，副本没有来得及提交，数据也没有了；
 *  消息消费的两个接口：Low-level API 和High-level API；
    
     *  Low-level API 低配版API，消费者自己维护offset，完全控制kafka；
     *  High-level API 高配版API，封装了对partition和offset的管理，傻瓜式使用就行了；如果消费者进行消息消费，刚拿到数据提交了新的offset，突然挂了，那这个消息就没有了。