面试准备（六） Kafka

谁践踏了优雅 2022-10-11 03:59 125阅读 0赞

### **一、Kafka概述** ###

Kafka是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统，常见用于web/nginx日志、访问日志，消息服务等。

Kafka的设计目标如下：

1、以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保持常数时间的访问性能。

2、高吞吐率。即使在非常廉价的商用机器上也能做到单机支持没鸟100000条消息的传输。

3、支持Kafka Server间的消费分区以及分布式消费，同时能保证每个partition内的消息顺序传输。

4、同时支持离线数据处理和实时数据处理。

### **二、Zookeeper和Kafka的关系** ###

kafka 0.9版本之前偏移量存储在zk

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

### **三、Kafka的数据可靠性和重复消费** ###

kafka通过ack来保证数据的可靠性，为了保证生产者发送的数能够可靠的发送到指定的topic，topic的每个partition收到生产者发送的数据中后，都需要向生产者发送ack（确认收到），如果生产者收到ack就会进行下一轮的发送，否则重新发送数据。

** **  那么kafka什么时候向生产者发送ack

确保follower和leader同步完成，leader在发送ack给生产者，这样才能确保leader挂掉之后，能再follower中选举出新的leader后，数据不会丢失

那多少个follower同步完成后发送ack

方案1：半数已经完成同步，就发送ack

方案2：全部完成同步，才发送ack（kafka采用这种方式）

采用第二种方案后，设想以下场景，leader收到数据，所有的follower都开始同步数据，但是有一个follower因为某种故障，一直无法完成同步，那leader就要一直等下，直到他同步完成，才能发送ack，这样就非常影响效率，这个问题怎么解决？

Leader维护了一个动态的ISR列表（同步副本的作用），只需要这个列表的中的follower和leader同步；当ISR中的follower完成数据的同步之后，leader就会给生产者发送ack，如果follower长时间未向leader同步数据，则该follower将被剔除ISR，这个时间阈值也是自定义的；同样leader故障后，就会从ISR中选举新的leader

怎么选择ISR的节点呢？

首先通信的时间要快，要和leader要可以很快的完成通信，这个时间默认是10s

然后就看leader数据差距，消息条数默认是10000条（后面版本被移除）

为什么移除：因为kafka发送消息是批量发送的，所以会一瞬间leader接受完成，但是follower还没有拉取，所以会频繁的踢出加入ISR，这个数据会保存到zk和内存中，所以会频繁的更新zk和内存。

但是对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等ISR中的follower全部接受成功

所以kafka为用户提供了三种可靠性级别，用户可以根据可靠性和延迟进行权衡，这个设置在kafka的生成中设置：acks参数设置

A、acks为0

生产者不等ack，只管往topic丢数据就可以了，这个丢数据的概率非常高

B、ack为1

Leader落盘后就会返回ack，会有数据丢失的现象，如果leader在同步完成后出现故障，则会出现数据丢失

C、ack为-1（all）

Leader和follower（ISR）落盘才会返回ack，会有数据重复现象，如果在leader已经写完成，且follower同步完成，但是在返回ack的出现故障，则会出现数据重复现象；极限情况下，这个也会有数据丢失的情况，比如follower和leader通信都很慢，所以ISR中只有一个leader节点，这个时候，leader完成落盘，就会返回ack，如果此时leader故障后，就会导致丢失数据

###    **四、消息队列的Push 和 Pull** ###

** ** push模式就相当于微信公众号，push模式很难适应消费速率不同的消费者，因为消费发送速率是由broker决定的，他的目标是尽可能以最快的速度传递消息，这样很容易造成消费者来不及处理数据。

Kafka使用的是pull的方式，pull的方式可以以消费者的消费能力以适当的速度进行消费。Pull的模式不足之处是如果kafka没有数据，消费者可能会陷入死循环，一直返回空数据，针对这一点，kafka的消费者在消费数据时候回传递一个timeout参数，如果当时没有数据可供消费，消费者会等待一段时间在返回。

### **五、Kafka的 rebalance** ###

**  **[https://www.cnblogs.com/hapjin/p/10926882.html?wework\_cfm\_code=NdcSXJwJZakw3WdR%2BaA1kDhvVeENxZK5W2%2BuJfZ4moOX%2FdxhjUTFDjNZgSCEOkcl0KOzXEnEqqGqaurOsky3HZpbnbXdDB10LnABdt2WtSDAFARDMPQsMwM%3D][https_www.cnblogs.com_hapjin_p_10926882.html_wework_cfm_code_NdcSXJwJZakw3WdR_2BaA1kDhvVeENxZK5W2_2BuJfZ4moOX_2FdxhjUTFDjNZgSCEOkcl0KOzXEnEqqGqaurOsky3HZpbnbXdDB10LnABdt2WtSDAFARDMPQsMwM_3D]

### **六、为什么使用Kafka  ** ###

缓冲和削峰：上游数据时有突发流量，下游可能扛不住，或者下游没有足够多的机器来保证冗余，kafka在中间可以起到一个缓冲的作用，把消息暂存在kafka中，下游服务就可以按照自己的节奏进行慢慢处理。

解耦和扩展性：项目开始的时候，并不能确定具体需求。消息队列可以作为一个接口层，解耦重要的业务流程。只需要遵守约定，针对数据编程即可获取扩展能力。

冗余：可以采用一对多的方式，一个生产者发布消息，可以被多个订阅topic的服务消费到，供多个毫无关联的业务使用。

健壮性：消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进行。

异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

[https_www.cnblogs.com_hapjin_p_10926882.html_wework_cfm_code_NdcSXJwJZakw3WdR_2BaA1kDhvVeENxZK5W2_2BuJfZ4moOX_2FdxhjUTFDjNZgSCEOkcl0KOzXEnEqqGqaurOsky3HZpbnbXdDB10LnABdt2WtSDAFARDMPQsMwM_3D]: https://www.cnblogs.com/hapjin/p/10926882.html?wework_cfm_code=NdcSXJwJZakw3WdR%2BaA1kDhvVeENxZK5W2%2BuJfZ4moOX%2FdxhjUTFDjNZgSCEOkcl0KOzXEnEqqGqaurOsky3HZpbnbXdDB10LnABdt2WtSDAFARDMPQsMwM%3D