这是一个创建于 46 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天刚面了一家公司，因为业务中有用到 Kafka ，所以就问了为什么使用这个，与其它中间件横向对比有了解吗。
于是我就从吞吐量、延迟、社区活跃度、开发语言之类的地方简单对比了下，然后说剩下的原因就是因为公司是这个技术栈，正好用来接收上游业务消息，所以选择 Kafka 。
接着对方就结束了这个问题，没有继续往下问，我总感觉他想知道的不是这个，亦或者说这个答案并不充分（我自己其实也有点这么感觉，感觉应该结合下业务之类的）。 如果是想考你技术选型的话，大伙遇到这种问题一般会怎么答
43 条回复 • 2024-10-21 15:22:38 +08:00
 |
1
mooyo 46 天前
他只是随便问问你对 kafka 的看法而已，你别想太多。
|
 |
2
yichya 46 天前
一般来说这种横向对比基本上就是找个切入点吧，看下对某个组件是否熟悉，熟悉就接着问，不熟悉就下个话题了。
主要是一问一个不知道也挺浪费时间的。。。 |
 |
3
tyrantZhao 46 天前  4
这个是小兵能选择的么？
|
 |
4
skull 46 天前
他只是随便问问你对 kafka 的看法而已，你别想太多。
|
 |
5
v2taylor 46 天前
多数公司实际上用哪个都一样，没必要想太多，哈哈
|
 |
6
Rust2015 46 天前
仅仅是从侧面了解你一下
|
 |
7
8355 46 天前 25
我来解释一下吧，这个题属于答不出来没啥，答出来有惊喜
最核心的区别 Kafka 是磁盘存储 消息延迟相对高 但可以承受大量的消息囤积 吞吐量超大 并且支持批量处理 通常应用于大数据/写日志/前端埋点上报等等对消费延迟不敏感但量大的业务，更适合一般业务。 RabbitMQ 是内存存储 延迟极低 因为内存容量问题不能承受大量消息囤积，适合实时性高的快速消费业务 通常应用于订单流转/广告上报，必须要开启足够多的冗余消费者还要保证消费的快速不阻塞，对监控要求极高，打满就挂了，更适合高实时性的分发类业务还可以 exchange 由一个队列分发到 n 个队列不同微服务分别消费。 |
 |
8
lpe234 46 天前
其实就是简单的了解一下。比如我大多数都在使用 RabbitMQ ，很少使用 Kafka 。我的回答是我对 RabbitMQ 比较熟，虽然语言是 Erlang ，吞吐量不如 Kafka 等，但我对 RabbitMQ 比较熟，出了问题我基本能处理，而且业务场景也没有非要使用其他 MQ 的需求、或者说 RabbitMQ 不适合的场景。然后再说一些自己对其他 MQ 的理解，优缺点等等。说白了，就是看你在工作中有没有思考过，还是只是一个单纯闷头干活的人。
|
 |
9
ChenKeLiang 46 天前
就是面试题库而已
|
 |
10
a1oyss0925 OP |
|
11
a1oyss0925 OP @8355 大哥牛逼，我再按照这个思路理理
|
|
12
a1oyss0925 OP @lpe234 感觉这么说也可以，就能让人知道你思考了
|
 |
13
adoal 46 天前
俗话说，没有既要又要还要……同类产品的选型，一定是评估各自的实际优缺点，选择跟自己业务最关心的长处切合的产品，再通过应用开发时的架构设计来规避掉它的缺点。所以，如果面试官自己都用过或者有都用过的人给准备材料的话，是可以从回答中看出应聘者是背八股还是真的有经验。比如消息时效性、有序性、消息回溯、死信处理等，不同产品的侧重点不一样，有的支持这个特性好，有的支持那个特性好，就需要根据自己的需要做选择以及通过应用编程闭坑。
|
 |
14
lolizeppelin 46 天前
rabbitmq 最初是金融系统用的,着重于确保消息到达,由于设计得早,没那么分布式,有完整 ampq 协议实现
Kafka 最初是用来退数据流的,着重效率,允许少量丢失,不支持 ampq 协议 随着版本发展,Kafka 确达功能比较完善了,但是依旧不支持 ampq rabbitmq 性能虽然提升了不少,但是整体架构不那么分布式,而且着重确达,所以性能还是和 kafka 有差距,不是和拿来做日志流的消息总线 |
 |
15
codegenerator 46 天前
就是看你是对技术仅仅是使用层面，还是你深入理解底层原理
从你的回答显然只是会使用的层次，而公司希望是对使用的技术全面掌握底层原理 如果你不仅深入掌握每个 mq 的底层原理，而且还能据此分析每个 mq 的各种使用场景的优缺点 从而进行技术选型，那么这个问题你就能拿满分 |
|
16
8355 46 天前 1
@a1oyss0925 #11 kafka 上了 serverless 版本真的屌的飞起 最低配一个小时推几十亿真的洒洒水
|
 |
17
zyqbit 46 天前
可以关注下 Pulsar
|
|
18
a1oyss0925 OP @codegenerator 对，其实我就是想答第二种，怎么根据业务场景进行技术选型，无奈知识储备不够
|
 |
19
encro 46 天前
@codegenerator
@a1oyss0925 是 15 楼的意思。。。 这属于开放性问题，能找出真正优秀的人。 这种人就是---基础牢固，经验丰富，善刨根究底，知其然并知其所以然，是不可多得的人才。 |
|
21
codegenerator 46 天前 1
@a1oyss0925 需要深入掌握相关技术的底层和实现原理，需要花费大量的时间研究，甚至是阅读相关代码
网络上很多技术问题其实有很多回答，但是真正靠谱的很少 比如技术选型 kafka 还是 rocketmq ，mysql 还是 postgredb 这一类问题 很多回答其实根本就没把原理和优缺点讲清楚，一方面要掌握原理另一方面也要根据业务场景分析才行 技术并不是一种就比另一种好，只有合适的才是最好的 我可以建一个 qq 群，大家互相探讨技术原理和源码，以及适用场景 870794652 |
 |
22
catamaran 46 天前
有时候是面试官想知道答案
|
 |
23
cheng6563 46 天前
@lolizeppelin #14 额。erlang 不是专为分布式而生的吗
|
|
24
8355 46 天前 3
@rqxiao 先说结论我用过的高负载 mq 没有一个开启持久化，redis 也是有 AOF 对吧，你们会开吗？
就算有磁盘持久化也只是另外的程序去异步刷盘，不会是运行一个命令就往磁盘写一次，肯定是每隔一段时间进行一次刷盘操作，道理是通用的，那一旦崩掉重启必然是丢失未刷盘的数据，因为你要从磁盘恢复数据。 mq 默认的刷盘时间是 25ms ，在高并发时期，大量推和大量消费，在海量数据持续刷盘的过程中势必产生额外的 cpu 开销，同时你还得保证你的磁盘 io 一定够用，不然潜在丢失的数据会更多。所以高并发肯定是不开启持久化。 既然在高负载时期崩掉必然会丢失数据，那么从调用 mq 前起码你应该入库以在崩溃时保证数据本身不会彻底丢失，这是最底线，所以也必然有修复丢失数据的机制，消息本身通常是某个微服务的处理结果，也就是说丢失数据本身只是影响的数据的实时性不可能因为 mq 崩溃导致整个系统链路彻底挂掉，消费设计有幂等可以保证上游系统重推也能有数据一致性。在架构设计完整的情况下，我们是不是应该把有限的资源给到关键的队列计算而不是刷盘这种备用方案，我需要的是它不挂而不是挂了尽量少丢数据。这个技术选型的目的就是极致的实时性，挂了就按照各自的业务走备用方案回溯。 |
 |
26
fffq 46 天前
公司用啥我用啥
|
 |
28
wuhunyu 46 天前
@8355 提一个疑问，在高并发情况下，在调用 mq 之前需要入库吗（我没啥高并发的经验，还是比较信任 mq 的）。我的疑问是，既然已经是高并发了，入库算是一个比较耗时的 io 操作了，入库虽然保证了数据的安全性，但也降低了高并发。如果把去掉入库操作，换成 mq 的同步刷盘（或者异步刷盘），两者对比会怎么样呢
|
|
29
codegenerator 46 天前
@wuhunyu 他讲的就是错的，mq 高并发跟数据库就没有关系
|
 |
30
k9982874 46 天前 via Android
这帖子恍惚回到了疫情前的 v2
|
 |
34
darkengine 46 天前
关于选型的问题，多看看 Kafka 和 RabbitMQ （或者任何其他同类技术）的 battle 帖子就能略知一二了。然后再结合实际项目中的经验总结一下。
|
 |
35
ivvei 45 天前
我面试人也经常会问些选型问题。主要是想考察这么几点：
1. 看看这个人是否对用到的东西有所思考。我不希望招一个只会让做什么就做什么的纯执行的机器，我希望招的是一个有自己的想法，能不断思考，找到新的好的合适的解决方法的。 2. 看看这个人对手上东西的了解深度。是深入地了解了，还是只会最粗浅的用法。 3. 看看这个人的思路、逻辑。选型嘛，必然有个好坏的比较过程。那么怎么判断哪些是好的是适合自己项目的，在取舍的时候更看重哪一些点。 |
|
36
ivvei 45 天前
@ivvei #35 接上文。
那么这样目的下回答成什么样会得怎样的分呢？ 扣分型： 1. 不懂但是要硬拗的。我会觉得这人不实在。 2. 思路混乱的。比如提一些系统的特性但是和自己的目的完全不搭。 不过不失： 1. 说是别人选的，自己只是用。0 分，当我没问过，下一题 得分型： 1. 多少能说出点道理的。理解可能不够深入，或者只会简单使用，但是逻辑能自洽。因为实际项目里用到的东西可能很多，很少有人能了解每个细节，所以有部分理解得比较简单的也是情有可原的。 2. 能精准地点评各类软件的优缺点，并给出充足的选或者不选的依据的。这样的我会给大加分。 |
 |
37
wssy001 45 天前
web 后端业务还有用 RabbitMQ ？有这需求为啥不上 RocketMQ
Kafka 和 RocketMQ 的选型就在于你的场景是业务型还是吞吐量优先（比如数据迁移），没记错的话，Kafka 是针对磁盘顺序写入做了优化，topic 一多，性能会低于 RocketMQ |
 |
38
hefish 45 天前 1
流水线工人面试
车间主任： 请问我们上的了个螺丝钉，为什么要上在火箭发动机的这个位置？能不能上在下面或者上面一点，分别有什么优缺点？ 工人： 不为什么，因为螺丝孔在那个位置。。。 |
 |
39
Cola98 45 天前
感觉你回答没什么问题，可以从业务场景中出发对比其他中间件，说下为什么使用 kafka ，差不多到这里就可以了。如果还要深入的话，就涉及到相关特点了。
|
 |
40
wlm201219 45 天前
大多数情况下，并不是想知道什么。只是搜到的面试题里面正好有这道题就问了
|
 |
41
weeei 45 天前
真的就是随便问问，你随便回答就行：
1. 对比它们的底层实现，或者对比他们的架构设计 2. 根据你自己的理解，对比在业务中各自适用的场景 3. 你也可以回答，你们想用什么我都行，有问题我也能处理 如果从雇佣方的角度，第 3 种回答可能会最先 pass ，也没啥特别的原因，就是对比其他两种回答，这个回答无法量化面试者的能力。 |
 |
42
cloverzrg2 43 天前
看你对这些中间件的理解吧
|
 |
43
sngxx 43 天前
@lolizeppelin 我说哪里不对劲呢兄弟，amqp
|
Select Language