V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
a1oyss0925
V2EX  ›  程序员

当面试官问为什么选择 Kafka/RabbitMQ/RocketMQ 时,他到底想问什么?

  •  
  •   a1oyss0925 · 31 天前 · 5288 次点击

    今天刚面了一家公司,因为业务中有用到 Kafka ,所以就问了为什么使用这个,与其它中间件横向对比有了解吗。

    于是我就从吞吐量、延迟、社区活跃度、开发语言之类的地方简单对比了下,然后说剩下的原因就是因为公司是这个技术栈,正好用来接收上游业务消息,所以选择 Kafka 。

    接着对方就结束了这个问题,没有继续往下问,我总感觉他想知道的不是这个,亦或者说这个答案并不充分(我自己其实也有点这么感觉,感觉应该结合下业务之类的)。 如果是想考你技术选型的话,大伙遇到这种问题一般会怎么答

    43 条回复    2024-10-21 15:22:38 +08:00
    mooyo
        1
    mooyo  
       31 天前
    他只是随便问问你对 kafka 的看法而已,你别想太多。
    yichya
        2
    yichya  
       31 天前
    一般来说这种横向对比基本上就是找个切入点吧,看下对某个组件是否熟悉,熟悉就接着问,不熟悉就下个话题了。

    主要是一问一个不知道也挺浪费时间的。。。
    tyrantZhao
        3
    tyrantZhao  
       30 天前   ❤️ 4
    这个是小兵能选择的么?
    skull
        4
    skull  
       30 天前
    他只是随便问问你对 kafka 的看法而已,你别想太多。
    v2taylor
        5
    v2taylor  
       30 天前
    多数公司实际上用哪个都一样,没必要想太多,哈哈
    Rust2015
        6
    Rust2015  
       30 天前
    仅仅是从侧面了解你一下
    8355
        7
    8355  
       30 天前   ❤️ 24
    我来解释一下吧,这个题属于答不出来没啥,答出来有惊喜
    最核心的区别
    Kafka 是磁盘存储 消息延迟相对高 但可以承受大量的消息囤积 吞吐量超大 并且支持批量处理
    通常应用于大数据/写日志/前端埋点上报等等对消费延迟不敏感但量大的业务,更适合一般业务。

    RabbitMQ 是内存存储 延迟极低 因为内存容量问题不能承受大量消息囤积,适合实时性高的快速消费业务
    通常应用于订单流转/广告上报,必须要开启足够多的冗余消费者还要保证消费的快速不阻塞,对监控要求极高,打满就挂了,更适合高实时性的分发类业务还可以 exchange 由一个队列分发到 n 个队列不同微服务分别消费。
    lpe234
        8
    lpe234  
       30 天前
    其实就是简单的了解一下。比如我大多数都在使用 RabbitMQ ,很少使用 Kafka 。我的回答是我对 RabbitMQ 比较熟,虽然语言是 Erlang ,吞吐量不如 Kafka 等,但我对 RabbitMQ 比较熟,出了问题我基本能处理,而且业务场景也没有非要使用其他 MQ 的需求、或者说 RabbitMQ 不适合的场景。然后再说一些自己对其他 MQ 的理解,优缺点等等。说白了,就是看你在工作中有没有思考过,还是只是一个单纯闷头干活的人。
    ChenKeLiang
        9
    ChenKeLiang  
       30 天前
    就是面试题库而已
    a1oyss0925
        10
    a1oyss0925  
    OP
       30 天前
    @skull 有时候就感觉这种问题怎么答都不对,又不能说公司让用什么我用什么
    @v2taylor 应该是这样,毕竟选型又不是我选
    a1oyss0925
        11
    a1oyss0925  
    OP
       30 天前
    @8355 大哥牛逼,我再按照这个思路理理
    a1oyss0925
        12
    a1oyss0925  
    OP
       30 天前
    @lpe234 感觉这么说也可以,就能让人知道你思考了
    adoal
        13
    adoal  
       30 天前
    俗话说,没有既要又要还要……同类产品的选型,一定是评估各自的实际优缺点,选择跟自己业务最关心的长处切合的产品,再通过应用开发时的架构设计来规避掉它的缺点。所以,如果面试官自己都用过或者有都用过的人给准备材料的话,是可以从回答中看出应聘者是背八股还是真的有经验。比如消息时效性、有序性、消息回溯、死信处理等,不同产品的侧重点不一样,有的支持这个特性好,有的支持那个特性好,就需要根据自己的需要做选择以及通过应用编程闭坑。
    lolizeppelin
        14
    lolizeppelin  
       30 天前
    rabbitmq 最初是金融系统用的,着重于确保消息到达,由于设计得早,没那么分布式,有完整 ampq 协议实现

    Kafka 最初是用来退数据流的,着重效率,允许少量丢失,不支持 ampq 协议

    随着版本发展,Kafka 确达功能比较完善了,但是依旧不支持 ampq

    rabbitmq 性能虽然提升了不少,但是整体架构不那么分布式,而且着重确达,所以性能还是和 kafka 有差距,不是和拿来做日志流的消息总线
    codegenerator
        15
    codegenerator  
       30 天前
    就是看你是对技术仅仅是使用层面,还是你深入理解底层原理
    从你的回答显然只是会使用的层次,而公司希望是对使用的技术全面掌握底层原理
    如果你不仅深入掌握每个 mq 的底层原理,而且还能据此分析每个 mq 的各种使用场景的优缺点
    从而进行技术选型,那么这个问题你就能拿满分
    8355
        16
    8355  
       30 天前   ❤️ 1
    @a1oyss0925 #11 kafka 上了 serverless 版本真的屌的飞起 最低配一个小时推几十亿真的洒洒水
    zyqbit
        17
    zyqbit  
       30 天前
    可以关注下 Pulsar
    a1oyss0925
        18
    a1oyss0925  
    OP
       30 天前
    @codegenerator 对,其实我就是想答第二种,怎么根据业务场景进行技术选型,无奈知识储备不够
    encro
        19
    encro  
       30 天前
    @codegenerator
    @a1oyss0925

    是 15 楼的意思。。。

    这属于开放性问题,能找出真正优秀的人。

    这种人就是---基础牢固,经验丰富,善刨根究底,知其然并知其所以然,是不可多得的人才。
    rqxiao
        20
    rqxiao  
       30 天前
    @8355 RabbitMQ 一般不也是会开启队列持久化吗
    codegenerator
        21
    codegenerator  
       30 天前   ❤️ 1
    @a1oyss0925 需要深入掌握相关技术的底层和实现原理,需要花费大量的时间研究,甚至是阅读相关代码
    网络上很多技术问题其实有很多回答,但是真正靠谱的很少
    比如技术选型 kafka 还是 rocketmq ,mysql 还是 postgredb 这一类问题
    很多回答其实根本就没把原理和优缺点讲清楚,一方面要掌握原理另一方面也要根据业务场景分析才行
    技术并不是一种就比另一种好,只有合适的才是最好的
    我可以建一个 qq 群,大家互相探讨技术原理和源码,以及适用场景
    870794652
    catamaran
        22
    catamaran  
       30 天前
    有时候是面试官想知道答案
    cheng6563
        23
    cheng6563  
       30 天前
    @lolizeppelin #14 额。erlang 不是专为分布式而生的吗
    8355
        24
    8355  
       30 天前   ❤️ 3
    @rqxiao 先说结论我用过的高负载 mq 没有一个开启持久化,redis 也是有 AOF 对吧,你们会开吗?
    就算有磁盘持久化也只是另外的程序去异步刷盘,不会是运行一个命令就往磁盘写一次,肯定是每隔一段时间进行一次刷盘操作,道理是通用的,那一旦崩掉重启必然是丢失未刷盘的数据,因为你要从磁盘恢复数据。
    mq 默认的刷盘时间是 25ms ,在高并发时期,大量推和大量消费,在海量数据持续刷盘的过程中势必产生额外的 cpu 开销,同时你还得保证你的磁盘 io 一定够用,不然潜在丢失的数据会更多。所以高并发肯定是不开启持久化。

    既然在高负载时期崩掉必然会丢失数据,那么从调用 mq 前起码你应该入库以在崩溃时保证数据本身不会彻底丢失,这是最底线,所以也必然有修复丢失数据的机制,消息本身通常是某个微服务的处理结果,也就是说丢失数据本身只是影响的数据的实时性不可能因为 mq 崩溃导致整个系统链路彻底挂掉,消费设计有幂等可以保证上游系统重推也能有数据一致性。在架构设计完整的情况下,我们是不是应该把有限的资源给到关键的队列计算而不是刷盘这种备用方案,我需要的是它不挂而不是挂了尽量少丢数据。这个技术选型的目的就是极致的实时性,挂了就按照各自的业务走备用方案回溯。
    zapper
        25
    zapper  
       30 天前   ❤️ 1
    @8355 #7 好久没有上 v2 学知识了
    fffq
        26
    fffq  
       30 天前
    公司用啥我用啥
    8355
        27
    8355  
       30 天前
    @rqxiao mysql 在这个场景更容易理解毕竟是肯定持久化的业务,可以查查 io wait 对 mysql 的影响,相关文档更好找也更容易理解。
    wuhunyu
        28
    wuhunyu  
       30 天前
    @8355 提一个疑问,在高并发情况下,在调用 mq 之前需要入库吗(我没啥高并发的经验,还是比较信任 mq 的)。我的疑问是,既然已经是高并发了,入库算是一个比较耗时的 io 操作了,入库虽然保证了数据的安全性,但也降低了高并发。如果把去掉入库操作,换成 mq 的同步刷盘(或者异步刷盘),两者对比会怎么样呢
    codegenerator
        29
    codegenerator  
       30 天前
    @wuhunyu 他讲的就是错的,mq 高并发跟数据库就没有关系
    k9982874
        30
    k9982874  
       30 天前 via Android
    这帖子恍惚回到了疫情前的 v2
    daimaosix
        31
    daimaosix  
       30 天前
    @8355 而你,我的朋友,让我在 V 站找到了学习的感觉
    daimaosix
        32
    daimaosix  
       30 天前
    @8355 大佬,安全系统推送威胁信息到 Kafka 还是 RabbitMQ 比较合适?有多个客户端,因为涉及到安全,所以必须快速的生产和消费数据。
    daimaosix
        33
    daimaosix  
       30 天前
    @8355 威胁数据的量不是特别大,但是也不是特别小,尤其遇到 CC 攻击时可能会生产大量的消息。
    darkengine
        34
    darkengine  
       30 天前
    关于选型的问题,多看看 Kafka 和 RabbitMQ (或者任何其他同类技术)的 battle 帖子就能略知一二了。然后再结合实际项目中的经验总结一下。
    ivvei
        35
    ivvei  
       30 天前
    我面试人也经常会问些选型问题。主要是想考察这么几点:

    1. 看看这个人是否对用到的东西有所思考。我不希望招一个只会让做什么就做什么的纯执行的机器,我希望招的是一个有自己的想法,能不断思考,找到新的好的合适的解决方法的。
    2. 看看这个人对手上东西的了解深度。是深入地了解了,还是只会最粗浅的用法。
    3. 看看这个人的思路、逻辑。选型嘛,必然有个好坏的比较过程。那么怎么判断哪些是好的是适合自己项目的,在取舍的时候更看重哪一些点。
    ivvei
        36
    ivvei  
       30 天前
    @ivvei #35 接上文。

    那么这样目的下回答成什么样会得怎样的分呢?

    扣分型:
    1. 不懂但是要硬拗的。我会觉得这人不实在。
    2. 思路混乱的。比如提一些系统的特性但是和自己的目的完全不搭。

    不过不失:
    1. 说是别人选的,自己只是用。0 分,当我没问过,下一题

    得分型:
    1. 多少能说出点道理的。理解可能不够深入,或者只会简单使用,但是逻辑能自洽。因为实际项目里用到的东西可能很多,很少有人能了解每个细节,所以有部分理解得比较简单的也是情有可原的。
    2. 能精准地点评各类软件的优缺点,并给出充足的选或者不选的依据的。这样的我会给大加分。
    wssy001
        37
    wssy001  
       29 天前
    web 后端业务还有用 RabbitMQ ?有这需求为啥不上 RocketMQ
    Kafka 和 RocketMQ 的选型就在于你的场景是业务型还是吞吐量优先(比如数据迁移),没记错的话,Kafka 是针对磁盘顺序写入做了优化,topic 一多,性能会低于 RocketMQ
    hefish
        38
    hefish  
       29 天前   ❤️ 1
    流水线工人面试
    车间主任: 请问我们上的了个螺丝钉,为什么要上在火箭发动机的这个位置?能不能上在下面或者上面一点,分别有什么优缺点?
    工人: 不为什么,因为螺丝孔在那个位置。。。
    Cola98
        39
    Cola98  
       29 天前
    感觉你回答没什么问题,可以从业务场景中出发对比其他中间件,说下为什么使用 kafka ,差不多到这里就可以了。如果还要深入的话,就涉及到相关特点了。
    wlm201219
        40
    wlm201219  
       29 天前
    大多数情况下,并不是想知道什么。只是搜到的面试题里面正好有这道题就问了
    weeei
        41
    weeei  
       29 天前
    真的就是随便问问,你随便回答就行:
    1. 对比它们的底层实现,或者对比他们的架构设计
    2. 根据你自己的理解,对比在业务中各自适用的场景
    3. 你也可以回答,你们想用什么我都行,有问题我也能处理
    如果从雇佣方的角度,第 3 种回答可能会最先 pass ,也没啥特别的原因,就是对比其他两种回答,这个回答无法量化面试者的能力。
    cloverzrg2
        42
    cloverzrg2  
       27 天前
    看你对这些中间件的理解吧
    sngxx
        43
    sngxx  
       27 天前
    @lolizeppelin 我说哪里不对劲呢兄弟,amqp
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   940 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 19:34 · PVG 03:34 · LAX 11:34 · JFK 14:34
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.