kafka问答

Posted 2023-03-21 icodegarden

Kafka架构？

Kafka是一个典型的分布式系统，采用Leader/Follower模式，每个topic的partition都有属于自己的Leader/Follower

Kafka架构中的主要角色有Zookeeper、Controller、Leader、Follower、Producer、Consumer

Zookeeper在kafka中的作用？

zookeeper在kafka中主要起分布式协调作用，比如争抢创建临时节点成为controller、当broker离开集群时watch感知、保存集群数据（如topic对应的Leader/Follower节点地址）

Controller的作用？

controller除了具有一般broker功能外，还负责分区leader的选举

如何成为Controller？

在所有broker中第一个成功在zk中创建/controller临时节点，或创建/controller的broker离开后争抢成功创建/controller的broker叫做Controller，并获得新的更大数值的epoch （争抢失败的都会收到节点已存在）

其他节点会忽略来自低版本的epoch消息

Leader的作用？

每个partition都有1个leader；为了保证一致性，所有生产者和消费者的请求都通过leader

Leader的另一个任务是要搞清楚哪些follower的状态跟自己是一致的；如果follower无法跟leader保持一致，就不能成为leader

Leader怎么选举？

当一个新的topic的partion创建时，会通过集群中的leader均衡选出一个首选Leader

当一个broker（leader类型）离开集群，controller知道哪些partition需要新的leader，controller遍历这些partition的follower并确定谁成为新leader（简单来说是follower同步副本列表里的下一个），然后向新leader们、follower们发送谁是新leader、谁是follower的信息。随后新leader开始处理producer、consumer的请求，follower开始从leader复制消息

除了当前首领之外，每个分区都有一个 首选首领——创建topic时选定的首领就是分区的首选首领。之所以把它叫做首选首领，是因为在创建分区时，需要在broker之间均衡首领。默认情况下，kafka的auto.leader.rebalance.enable被设为true，它会检查首选首领是不是当前首领，如果不是，并且该副本是同步副本，那么就会触发首领选举，让首选首领成为当前首领。

如果leader不可用时，其他的副本都是不同步的，怎么处理？

方式1：分区在旧leader恢复前不可用，因为旧leader才是唯一的同步副本；

方式2：允许其他不同步的副本成为leader，也就是不完全的选举，但会导致该broker成为不同步副本后，producer写入旧leader的数据全部丢失，unclean.leader.election.enable 是否允许不完全选举，默认false

Follower的作用？

每个partition的Follower数量是根据配置的复制系数（默认3含leader，可以是broker级别，也可以是topic级别）来创建的

Follower不处理来自客户端的请求，唯一的任务就是向leader复制消息，与leader保持一致，以便在leader不可用时其中一个Follower被选举为下一个leader

Follower怎么向Leader复制消息？

follower向leader复制消息跟consumer消费读取消息是一样的

follower向leader发送offset读取下一个消息，leader也能知道每个follower的复制进度

什么是同步副本？哪些属于不同步副本？

同步副本指的是Follower与Leader的消息复制是最新的，只有同步副本才有资格选举leader

当Leader在10s内没有收到follower的复制请求，或者10s内收到的请求不是最新的消息， 或者Follower与zookeeper之间心跳检查失败（默认6s），就会认为不是同步副本；

不同步的副本会通过与zookeeper重新建立连接，从leader获取最新消息成为同步副本，通常这很快，除非发生崩溃需要修复

产生不同步副本的原因？有什么后果？

#网络不正常

#同步和不同步之间快速切换，可能是broker的不正常GC停顿导致与zookeeper之间断开

后果是：

#一个滞后的同步副本会导致消息的生产和消费变慢，因为只有已经被写入所有同步副本的消息才能被读取，除非已经被确认是不同步副本

#丢消息风险变大

Producer和Consumer怎么知道请求往哪里发？发错了会怎么样？

由于broker都向zookeeper进行了连接，当客户端连接到任意broker的时候，会得到元数据，其中包含topic和partition对应的leader地址，客户端就能正确的发送请求（客户端把元数据进行缓存，并按metadata.max.age.ms的频率进行请求刷新）

所有生产者和消费者的请求都通过leader，如果发到的不是leader，则会收到‘非分区首领’异常；客户端要自己负责发送到的是leader，kafka的SDK自动处理了发送到正确的leader，在收到非分区首领异常时进行元数据的请求刷新

Producer的ack有哪几种？与丢消息有什么关系？

#0通过网络发出去就认为成功，如果集群不可用、发送到了旧的leader等也无法感知；

#1 Leader收到消息并写入系统文件缓存就响应成功；

如果有3个副本，此时消息还没被同步副本复制过去，恰好leader不可用，新的leader产生了（判断一个副本不同步是需要一小段时间的），则消息会丢失；

如果follower都是不同步的，此时leader的操作系统挂了（数据还没来得及被刷盘），消息丢失

#all需要足够的同步副本复制成功才响应成功；

如果follower都是不同步的，此时leader的操作系统挂了（数据还没来得及被刷盘），消息丢失

Consumer是怎么读取消息的？

Consumer向leader发送读取的offset开始获取消息

不是所有保持在leader上的数据都可以被读取，只有已经被写入所有同步副本的消息才能被读取，否则kafka认为是不安全的；

leader知道每个消息会被复制到哪些副本上；因此如果消息复制变慢，则消息达到consumer的时间也会增加，延迟时间可以通过replica.lag.time.max.ms配置复制消息时可被允许的最大延迟时间

Broker是怎么均衡成为partition的leader和follower的?

broker间是平均分布副本；尽量使每个partition的副本在不同的broker上；

如果broker指定了机架，分区副本尽可能分配到不同的机架

环境：6个broker、1个由10个分区的topic，复制系数3；即共30个分区副本分给6个broker

分配过程：先分配leader，分区0leader在broker4，分区1leader在broker5，分区2leader在broker0…；再分配follower，因分区0leader在broker4，那它的第一个follower在broker5，第二个follower在broker0，以此类推…；如果配置了机架，则按机架交替方式选择broker

Broker中的消息什么时候刷盘?存储的文件如何管理？

默认异步刷盘，先写入到系统页缓存，然后由操作系统在合适的时间再刷新到日志文件即磁盘；页缓存的数据在操作系统不可用时可能会丢失

每个partition的数据会以分片文件方式存储（因为如果是一个大文件，查找和删除很费时还容易出错），默认每个分片文件1G或一周数据，先到为准，到了就关闭该文件并打开新的分片文件；当前正在写入的叫活动分片，活动分片不会删除，所以即使数据保留时间配置的小也不会删除活动分片文件

Broker会为每个partition的每个分片文件打开一个文件句柄，即使不是活动的，因此可能导致文件句柄过多，用户需要根据实际配置数据保留时间和操作系统文件策略优化

Kafka为什么性能吞吐量高?

#跟kafka优秀的分布式架构有关，理论上可以水平扩容到N多节点，使得不同topic不同partition的性能进行分摊

#使用系统文件缓存达到高性能存储，而不是频繁刷盘

#broker使用零拷贝技术处理客户端的消息请求，来自producer的消息直接从网络通道转到系统文件缓存，Consumer和follower的请求直接从系统文件缓存到网络通道，避免了内核空间和用户空间之间的内存复制、CPU对网络数据的处理

#kafka提供了消息压缩机制，producer发送的是压缩后的消息，消息头中包含了压缩方式，consumer收到之后以相同的方式进行解压，这中间的过程不影响零拷贝

什么是系统文件缓存?

操作系统实现的一种主要的磁盘缓存，以此用来减少对磁盘I/O的操作。具体来说，就是把磁盘中的数据缓存到内存中，把对磁盘的访问变成对内存的访问，当一个进程准备读取磁盘上的文件内容时，操作系统会先查看待读取的数据所在的页是否在页缓存中，如果存在则直接返回数据，从而避免了对物理磁盘的I/O操作；如果没有命中，则操作系统会向磁盘发起读取请求并将读取的数据页存入页缓存，之后再将数据返回给进程。同样，如果一个进程需要将数据写入磁盘，那么操作系统也会检测数据对应的页是否在页缓存中，如果不存在，则会先在页缓存中添加相应的页，最后将数据写入对应的页。被修改过后的页就变成了脏页，操作系统会在合适的时间把脏页中的数据写入磁盘，以保持数据的一致性。Kafka中大量使用了页缓存，这是Kafka实现高吞吐的重要因素之一。虽然消息都是先被写入页缓存，然后由操作系统负责具体的刷盘任务的，但在Kafka中同样提供了同步刷盘及间断性强制刷盘的功能，这些功能可以通过log.flush.interval.message、log.flush.interval.ms等参数来控制。同步刷盘可以提高消息的可靠性，防止由于机器掉电等异常造成处于页缓存而没有及时写入磁盘的消息丢失。消息的可靠性应该由多副本机制来保障，而不是由同步刷盘这种严重影响性能的行为来保障

Kafka在什么情况下会丢消息？如何做到不丢消息？

当producer使用的ack不是all时；

当consumer使用的是自动commit（默认每5s Consumer自动提交一次），消费失败时；

如何保障：

producer使用ack=all，合理使用重试次数如=2；

consumer使用手动commit，并在消费失败时增加重试机制；

在broker或topic级别配置 最少同步副本数min.insync.replicas=2以上（默认1即leader自己，ack=all即leader自己同步即可）

最少同步副本数 - 如果复制系数为3，最少同步副本数为2，那么当出现2个不同步副本时，leader将会停止接受producer的请求，收到NotEnoughReplicasException，而consumer可以继续消费。这项配置对消息的可靠性保证有意义，假设当produceracks=all，但此时副本都不是同步的，broker也会响应成功，此时若leader不可用，数据可能还未刷入磁盘，导致丢失；而如果配置了最少同步副本为2，那么procuder将会收到异常，而不是只写到leader上

Kafka在什么情况下会产生重复消息？

#Consumer在消费完消息但在提交offset前断开连接

#发生Consumer再均衡时(有Consumer加入或离开group)，partition可能被分配给另一个consumer从而另一个consumer也获取到了相同的数据

#网络原因producer重试发送消息

消息需要长时间处理有什么问题？

由于consumer需要与broker之间保持心跳（max.poll.interval.ms默认60秒）才能证明consumer还是在消费的（否则broker认为该消费者已不可用，进行再均衡，不给该consumer分配partition），因此如果消息处理时间过长而无法即使触发下一次poll，则会出问题

可以加大max.poll.interval.ms时间、使用线程池加快处理、使用pause来跳过该partition的poll处理完成再resume

Kafka与RabbitMQ的明显区别？

Kafka在消费时可能有重复消息，需要幂等处理

Kafka消息处理失败时没有自动重试机制，需要自己提供可靠保障机制

Kafka在丢消息不可容忍的场景下，需要关注消息生产和消费时的丢失问题

Kafka精华问答 | Kafka的主要应用场景有哪些？

Kafka是最初由Linkedin公司开发,具有高性能、持久化、多副本备份、横向扩展能力。今天，我们就看看看关于Kafka的精华问答吧。

1：

Q：什么是Kafka？

A：Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。

2

Q：消息队列实现原理

A：

3

Q：kafka的总体数据流是什么样的？

A：

4

Q：kafka 架构

A：

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

2）consumer：消息消费者，就是向 kafka broker 获取消息的客户端 

3）topic：消息类别，也可以理解为一个队列 

4）consumer group（CG）：这是 kafka 用来实现一个 topic 下的消息的广播语义（发给所有的 consumer）和单播语义（发给任意一个 consumer）的手段。一个 topic 可以有多个 consumer group。topic 下的消息会复制给 consumer。**如果需要实现广播，那么只要每个 consumer 有一个独立的 consumer group。要实现单播，只要所有的 consumer 在同一个 consumer group。**consumer group 还可以将 consumer 进行自由的分组，而不需要多次发送消息到不同的 topic。 

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.kafk a的文件即可。当然t he first offset 就是00000000000.kafka。

5

Q：主要功能有哪些？

A：根据官网的介绍，ApacheKafka®是一个分布式流媒体平台，它主要有3种功能：发布和订阅消息流，这个功能类似于消息队列，这也是kafka归类为消息队列框架的原因；以容错的方式记录消息流，kafka以文件的方式来存储消息流；可以再消息发布的时候进行处理。

小伙伴们冲鸭，后台留言区等着你！

关于Kafka，今天你学到了什么？还有哪些不懂的？除此还对哪些话题感兴趣？快来留言区打卡啦！留言方式：打开第XX天，答：……

同时欢迎大家搜集更多问题，投稿给我们！风里雨里留言区里等你~

福利

1、扫描添加小编微信，备注“姓名+公司职位”，加入【云计算学习交流群】，和志同道合的朋友们共同打卡学习！

推荐阅读：

真香，朕在看了！