kafka!还好我留了一手

·  阅读 17906
kafka!还好我留了一手

本文已参与「掘力星计划」,赢取创作大礼包,挑战创作激励金。

本文面试情节虚假,但知识真实,请在家人或者朋友的陪同下仔细观看,防止在观看的过程发呆、走神导致没学到知识。

性能篇

一位身穿格子衬衣,头发好似一拳超人的中年人走了过来,没错他就是面试官,他手握简历,若有所思,我当时害怕极了,然后他开口:小伙子啊,我们这边是基础架构的中间件组,既然你的简历没提到kafka,那我接下来问问你kafka的知识吧。

:好的,kafka平时看的不多,但也还了解一点,不是特别精通所以没写了。(嘿嘿,我是故意没写的,早就知道你要来这一套,kafka其实是俺最精通的东西了)
面试官捋了捋他那稀疏的胡须:那我们开始吧,先说说kafka的Log文件存在什么地方?
:kafka的topic可以分区,所以Log对应了一个命名形式为topic-partition的文件夹,比如对于一个有两个分区的topic来说,它的log分别存在xxx/topic-1和xxx/topic-2中。
面试官:那按照这样的说法,所以log文件的位置应该就是xxx/topic-1/data.log或者xxx/topic-2/data.log?
:不是的,kafka的log会分段,每个分区文件夹下,其实有很多的log段,它们共同组成了log,每个日志段大小是1G,如果一个日志段写完,会自动写入一个新的段。
面试官:为什么要分段?不分段行不行?
:分段可以很好的维护数据,首先不分段,当查找一条数据的时候会很麻烦,就像在一本没有目录的新华字典里找数据一样,如果分了段我们只要知道数据在哪个段中,然后在对应的段中查找即可。同时由于log是持久化磁盘的,磁盘的空间不可能无穷无尽的,当需要清除一些老数据,通过分段机制,只需要删除较老的数据段即可。
面试官:hold on,hold on~,你说分了段后我们只要知道数据在哪个段中即可,那么我们怎么知道数据在哪个段中的?
:easy,easy~,kafka内部维护一个跳跃表,跳跃表的节点就是每个段的段号。这样当查询数据的时候,先根据跳跃表就可以快速定位到目标数据段。
面试官:跳跃表是可以加速访问,但是每个段的段号是咋确定的?
:kakfa的段号其实就是根据偏移量来的,它代表当前段内偏移量最小的那条数据的offset,比如:

segment1的段号是200,segment2的段号是500,那么segment1就存储了偏移量200-499的消息。
面试官:嗯嗯,那定位到段后,如何定位到具体的消息,直接遍历吗?
:不是直接遍历,直接遍历效率太低,kafka采用稀疏索引的方式来搜索具体的消息,其实每个log分段后,除了log文件外,还有两个索引文件,分别是.index和.timeindex,

其中.index就是我说的偏移量索引文件,它不会为每条消息创建索引,它会每隔一个范围区间创建索引,所以称之为稀疏索引。

比如我们要查找消息6的时候,首先加载稀疏文件索引.index到内存中,然后通过二分法定位到消息5,最后通过消息5指向的物理地址接着向下顺序查找,直至找到消息6。
面试官:那稀疏索引的好处是什么?
:稀疏索引是一个折中的方案,既不占用太多空间,也提供了一定的快速检索能力。
面试官:上面你说到了.timeindex文件,它是干嘛的?
:这和kafka清理数据有着密切的关系,kafka默认保留7天内的数据,对于超过7天的数据,会被清理掉,这里的清理逻辑主要根据timeindex时间索引文件里最大的时间来判断的,如果最大时间与当前时间差值超过7天,那么对应的数据段就会被清理掉。
面试官:说到数据清理,除了你说的根据时间来判断的,还有哪些?
:还有根据日志文件大小和日志起始偏移量的方式,对于日志文件大小,如果log文件(所有的数据段总和)大于我们设定的阈值,那么就会从第一个数据段开始清理,直至满足条件。对于日志起始偏移量,如果日志段的起始偏移量小于等于我们设定的阈值,那么对应的数据段就会被清理掉。
面试官:你知道消息合并吗?如果知道说说消息合并带来的好处。
:了解一点,消息合并就是把多条消息合并在一起,然后一次rpc调用发给broker,这样的好处无疑会减少很多网络IO资源,其次消息会有个crc校验,如果不合并每条消息都要crc,合并之后,多条消息可以一起crc一次。
面试官:那合并之后的消息,什么时候会给broker?
:合并的消息会在缓冲区内,如果缓冲区快满了或者一段时间内没有生产消息了,那么就会把消息发给broker。
面试官:那你知道消息压缩吗?
:知道一点,压缩是利用cpu时间来节省带宽成本,压缩可以使数据包的体积变得更小,生产者负责将数据消息压缩,消费者拿到消息后自行解压。
面试官:所有只有生产者可以压缩?
:不是的,broker也可以压缩,当生产者指定的压缩算法和broker指定压缩算法的不一样的时候,broker会先按照生产者的压缩算法解压缩一下,然后再按照自己的压缩算法压缩一下,这是需要注意的,如果出现这种情况会影响整体的吞吐。还有就是新老版本的问题,如果新老版本的压缩算法不兼容,比如broker版本比较老,不支持新的压缩算法,那么也会发生一样的事情。
面试官:我们知道kafka的消息是要写入磁盘的,磁盘IO会不会很慢?
:是这样的,kafka的消息是磁盘顺序读写的,有关测试结果表明,一个由6块7200r/min的RAID-5阵列组成的磁盘簇的线性(顺序)写入速度可以达到 600MB/s,而随机写入速度只有 100KB/s,两者性能相差6000倍。操作系统可以针对线性读写做深层次的优化,比如预读(read-ahead,提前将一个比较大的磁盘块读入内存)和后写(write-behind,将很多小的逻辑写操作合并起来组成一个大的物理写操作)技术。顺序写盘的速度不仅比随机写盘的速度快,而且也比随机写内存的速度快。
面试官:顺序读写是为了解决了缓慢的磁盘问题,那在网络方面还有其他的优化吗?
:有,零拷贝,在没有零拷贝的时候,消息是这样交互的:

  1. 切到内核态:内核把磁盘数据copy到内核缓冲区
  2. 切到用户态:把内核的数据copy到用户程序
  3. 切到内核态:用户数据copy到内核socket缓冲区
  4. socket把数据copy给网卡

可以发现一份数据经过多次copy,最终兜兜转转又回到了内核态,实属浪费。

当有了零拷贝之后:

  1. 磁盘数据copy到内核缓冲
  2. 内核缓冲把描述符和长度发给socket,同时直接把数据发给网卡

可以发现通过零拷贝,减少了两次copy过程,大大降低了开销。

可靠篇

面试官:(关于性能方面的问的差不多了,接下来换换口味吧),kafka的多消费者模型是怎么做到的?
:如果要支持多个消费者同时消费一个topic,最简单的方式就是把topic复制一份,但这无疑会浪费很多空间,尤其在消费者很多的情况下,

于是kafka设计出一套offset机制,即一份数据,不同的消费者根据位置来获取不同的消息即可。

面试官:那你知道消费者的offset存在哪吗?
:很久以前,是存在zookeeper中的,但是offset需要频繁更新,zookeeper又不适合频繁更新,所以后来就把消费者位移存在了一个叫_consumer_offset的topic中,这个topic会在第一个消费者启动的时候自动创建,默认50个分区,3个副本。
面试官:那你说说这个_consumer_offset里面具体存了什么?
:这里其实主要分为key和value,value可以简单的认为就是我们的消费者位移,关于key,这里要细说下,由于每个消费者都属于一个消费者组,并且每个消费者其实消费的是某个topic的分区,所以通过group-topic-partition就可以关联上对应的消费者了,这也就是key的组成。
面试官:那你能介绍下消费者提交位移的方式吗?
:这里分为自动提交和手动提交。自动提交的话,就不需要我们干预,我们消费完消息后,kafka会自动帮我们提交,手动提交的话,就需要我们在消费到消息后自己主动commit。
面试官:自动提交会有什么问题?
:自动提交的策略是consumer默认每隔5秒提交一次位移,如果consumer在接下来的很长时间内都没有数据消费,那么自动提交策略就会一直提交重复的位移,导致_consumer_offset有很多重复的消息。
面试官:那这有什么解决方案吗?
:有,这种情况的核心问题就是可能会有大量的、重复的位移消息占用存储空间,只要把重复的去掉即可,kafka提供一种类似redis的aofrewrite的功能,叫compact策略,compact是由一个logCleaner线程来完成的,它会把重复的、并且较老的消息清除掉。

面试官:那如果consumer自动重启了,位移没来的及提交咋办?
:这个会造成重复消费,一般业务上需要配合做幂等。
面试官:那手动提交能解决这个问题吗?
:不能,如果我们在业务处理完之后手动提交,但是在还没得及提交的情况下,也发生了重启或者其他原因导致提交不上去,在消费者恢复后也会发生重复消费。
面试官:那如果我是先提交,后处理业务逻辑呢?
:这种情况也不能保证100%没问题,如果提交成功,但是处理业务时出错,正常来说,这时希望重新消费这条数据是不行的,因为已经提交了,除非你重置offset。总之无论哪种方案都不能保证100%的完美,我们需要自己根据业务情况做幂等或者根据log来找到丢失的数据。
面试官:消费者提交消费位移时提交的是是当前消费到的最新消息的offset还是offset+1?
:offset+1。
面试官:从生产者的角度谈谈消息不丢失的看法。
:关于消息丢失问题,kafka的生产者提供了3种策略来供使用者选择,每种策略各有利弊,需要结合业务的实际状况来选择。

  1. 第一种就是生产者不关心消息的情况,只负责发,这种模式无疑速度是最快的,吞吐是最好的,但是可能造成大量的数据丢失,比如在borker出现问题的时候,生产者还不停的发,那么到broker恢复期间的数据都将丢失。
  2. 第二种就是生产者需要所有副本都写入成功,不管是Leader副本还是Follower副本,那么当Follower副本越多,吞吐理论就越差,但是这种模式下,消息是最安全的。
  3. 第三种就是生产者只需要收到Leader副本的ack即可,不用关心Follower副本的写入情况,它是个折中的做法,保证了一定的安全性的同时也不会太影响吞吐。

如果你不在意自己的数据丢失问题,追求吞吐,比如像log这种,可以采用第一种,如果你非常在意自己的数据安全性,那么就选第二种。如果你希望吞吐稍微好点,同时数据又能安全些,建议第三种,但是第三种在Follower副本出现的问题的时候对生产者来说是无法感知的。

面试官:那你说说一个Follower副本如何被选举成Leader的?
:在kafka中有这样几个概念:

  • AR:所有副本集合
  • ISR:所有符合选举条件的副本集合
  • OSR:落后太多或者挂掉的副本集合

AR = ISR + OSR,在正常情况下,AR应该是和ISR一样的,但是当某个Follower副本落后太多或者某个Follower副本节点挂掉了,那么它会被移出ISR放入OSR中,kafka的选举也比较简单,就是把ISR中的第一个副本选举成新的Leader节点。比如现在AR=[1,2,3],1挂掉了,那么ISR=[2,3],这时会选举2为新的Leader。

面试官捋了捋自己左边的刘海:你还有什么要问我的吗?
:老师,请问你会组合拳吗?

面试官:组合拳我不会,但是等会会有很多人组合过来面你。

未完待续...

往期精彩:

kafka扫盲-思考与实现
一个简单的删除,我发现这么多知识...
一文搞懂回滚和持久化

最后,微信搜【假装懂编程】,如果你有任何疑问,欢迎联系我,如果我的文章有问题,也欢迎指正,如果你爱学习,喜欢钻研,可以关注我。

分类:
后端
收藏成功!
已添加到「」, 点击更改