前言
有些人害怕自己的学历会影响自己在投简历的时候会因为学历低的原因被HR直接筛选掉!
那么,大厂为什么会要求高学历?
- 因为读过书的人对待事情有一定的逻辑性,有人说读书没有用,但大家都没注意到,读书会潜移默化影响我们的思想,一些处理事情的方法。
- 没有学历的人中会有这么几类人,第一种那就是千里马,也就是无文凭人才。第二种人就是不思进取,安于现状的人。第三种人没学识,没文化的人,等着天上掉馅饼的人。
像无文凭这种人才在社会非常少,而且混在人群中,如果你是管理者,你要怎么分辨哪些是人才,哪些是蠢才。作为公司,目的就是赚钱,没有时间,也不会花太经历来分辨社会中哪些人会对自己有用。
所以努力思考才是大厂所需要的,而不是高学历!
平凡与卓越的差距就在于,有人埋怨生活,有人改变生活。
正文
问题一:为什么使用消息队列?消息队列有什么优点和缺点?Kafka、 ActiveMQ、RabbitMQ、RocketMQ 都有什么优点和缺点?
面试官心理分析
其实面试官主要是想看看:
- 第一,你知不知道你们系统里为什么要用消息队列这个东西?
不少候选人,说自己项目里用了 Redis、MQ,但是其实他并不知道自己为什么要用这个东西。其实说白了, 就是为了用而用,或者是别人设计的架构,他从头到尾都没思考过。
没有对自己的架构问过为什么的人,一定是平时没有思考的人,面试官对这类候选人印象通常很不好。因 为面试官担心你进了团队之后只会木头木脑的干呆活儿,不会自己思考。
- 第二,你既然用了消息队列这个东西,你知不知道用了有什么好处&坏处?
你要是没考虑过这个,那你盲目弄个 MQ 进系统里,后面出了问题你是不是就自己溜了给公司留坑?你要 是没考虑过引入一个技术可能存在的弊端和风险,面试官把这类候选人招进来了,基本可能就是挖坑型选手。 就怕你干 1 年挖一堆坑,自己跳槽了,给公司留下无穷后患。
- 第三,既然你用了 MQ,可能是某一种 MQ,那么你当时做没做过调研?
你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个 MQ,比如 Kafka,甚至都从没调研过业界流行的 MQ 到底有哪几种。每一个 MQ 的优点和缺点是什么。每一个 MQ 没有绝对的好坏,但是就是看用在哪个场景可以 扬长避短,利用其优势,规避其劣势。
如果是一个不考虑技术选型的候选人招进了团队,leader 交给他一个任务,去设计个什么系统,他在里面 用一些技术,可能都没考虑过选型,最后选的技术可能并不一定合适,一样是留坑。
面试题剖析
为什么使用消息队列?
其实就是问问你消息队列都有哪些使用场景,然后你项目里具体是什么场景,说说你在这个场景里用消息队列是什么?
面试官问你这个问题,期望的一个回答是说,你们公司有个什么业务场景,这个业务场景有个什么技术挑战, 如果不用 MQ 可能会很麻烦,但是你现在用了 MQ 之后带给了你很多的好处。
先说一下消息队列常见的使用场景吧,其实场景有很多,但是比较核心的有 3 个:解耦、异步、削峰。
解耦
看这么个场景。A 系统发送数据到 BCD 三个系统,通过接口调用发送。如果 E 系统也要这个数据呢?那如 果 C 系统现在不需要了呢?A 系统负责人几乎崩溃......
在这个场景中,A 系统跟其它各种乱七八糟的系统严重耦合,A 系统产生一条比较关键的数据,很多系统都 需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办?要不要重发, 要不要把消息存起来?头发都白了啊!
如果使用 MQ,A 系统产生一条数据,发送到 MQ 里面去,哪个系统需要数据自己去 MQ 里面消费。如果新 系统需要数据,直接从 MQ 里消费即可;如果某个系统不需要这条数据了,就取消对 MQ 消息的消费即可。 这样下来,A 系统压根儿不需要去考虑要给谁发送数据,不需要维护这个代码,也不需要考虑人家是否调用 成功、失败超时等情况。
总结:通过一个 MQ,
Pub/Sub
发布订阅消息这么一个模型,A 系统就跟其它系统彻底解耦了。
面试技巧:你需要去考虑一下你负责的系统中是否有类似的场景,就是一个系统或者一个模块,调用了多个 系统或者模块,互相之间的调用很复杂,维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的, 如果用 MQ 给它异步化解耦,也是可以的,你就需要去考虑在你的项目里,是不是可以运用这个 MQ 去进行 系统的解耦。在简历中体现出来这块东西,用 MQ 作解耦。
异步
再来看一个场景,A 系统接收一个请求,需要在自己本地写库,还需要在 BCD 三个系统写库,自己本地写 库要 3ms,BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms,接近 1s,用户感觉搞个什么东西,慢死了慢死了。用户通过浏览器发起请求,等待个 1s,这几 乎是不可接受的。
一般互联网类的企业,对于用户直接的操作,一般要求是每个请求都必须在 200 ms 以内完成,对用户几乎是无感知的。
如果使用 MQ,那么 A 系统连续发送 3 条消息到 MQ 队列中,假如耗时 5ms,A 系统从接受一个请求到返 回响应给用户,总时长是 3 + 5 = 8ms,对于用户而言,其实感觉上就是点个按钮,8ms 以后就直接返回 了,爽!网站做得真好,真快!
削峰
每天 0:00 到 12:00,A 系统风平浪静,每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 , 每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的,大量的请求涌入 MySQL,每秒 钟对 MySQL 执行约 5k 条 SQL。
一般的 MySQL,扛到每秒 2k 个请求就差不多了,如果每秒请求到 5k 的话,可能就直接把 MySQL 给打死 了,导致系统崩溃,用户也就没法再使用系统了。
但是高峰期一过,到了下午的时候,就成了低峰期,可能也就 1w 的用户同时在网站上操作,每秒中的请求 数量可能也就 50 个请求,对整个系统几乎没有任何的压力。
如果使用 MQ,每秒 5k 个请求写入 MQ,A 系统每秒钟最多处理 2k 个请求,因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求,每秒钟就拉取 2k 个请求,不要超过自己每秒能处理的最大请求数 量就 ok,这样下来,哪怕是高峰期的时候,A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来,就 2k 个请求出去,结果就导致在中午高峰期(1 个小时),可能有几十万甚至几百万的请求积压在 MQ 中。
这个短暂的高峰期积压是 ok 的,因为高峰期过了之后,每秒钟就 50 个请求进 MQ,但是 A 系统依然会 按照每秒 2k 个请求的速度在处理。所以说,只要高峰期一过,A 系统就会快速将积压的消息给解决掉。
消息队列有什么优缺点
优点上面已经说了,就是在特殊场景下有其对应的好处,解耦、异步、削峰。
缺点有以下几个:
- 系统可用性降低
系统引入的外部依赖越多,越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了,人 ABCD 四 个系统好好的,没啥问题,你偏加个 MQ 进来,万一 MQ 挂了咋整,MQ 一挂,整套系统崩溃的,你不就完 了?如何保证消息队列的高可用,可以点击这里查看。
- 系统复杂度提高
硬生生加个 MQ 进来,你怎么保证消息没有重复消费?怎么处理消息丢失的情况?怎么保证消息传递的顺 序性?头大头大,问题一大堆,痛苦不已。
- 一致性问题
A 系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是,要是 BCD 三个系统那里, BD 两个系统写库成功了,结果 C 系统写库失败了,咋整?你这数据就不一致了。
所以消息队列实际是一种非常复杂的架构,你引入它有很多好处,但是也得针对它带来的坏处做各种额外的 技术方案和架构来规避掉,做好之后,你会发现,妈呀,系统复杂度提升了一个数量级,也许是复杂了 10 倍。 但是关键时刻,用,还是得用的。
Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点?
综上,各种对比之后,有如下建议:
一般的业务系统要引入 MQ,最早大家都用 ActiveMQ,但是现在确实大家用的不多了,没经 过大规模吞吐量场景的验证,社区也不是很活跃,所以大家还是算了吧,我个人不推荐用这个了;
后来大家开始用 RabbitMQ,但是确实 erlang
语言阻止了大量的 Java 工程师去深入研究和掌控它,对公司而言,几乎处于不可控的状态,但是确实人家是开源的,比较稳定的支持,活跃度也高;
不过现在确实越来越多的公司会去用 RocketMQ,确实很不错,毕竟是阿里出品,但社区可能有突然黄掉的风险(目前 RocketMQ 已捐给 Apache,但 GitHub
上的活跃度其实不算高)对 自己公司技术实力有绝对自信的,推荐用 RocketMQ,否则回去老老实实用 RabbitMQ 吧,人 家有活跃的开源社区,绝对不会黄。
所以中小型公司,技术实力较为一般,技术挑战不是特别高,用 RabbitMQ 是不错的选择;大型公司,基础架构研发实力较强,用 RocketMQ 是很好的选择。
如果是大数据领域的实时计算、日志采集等场景,用 Kafka 是业内标准的,绝对没问题,社区 活跃度很高,绝对不会黄,何况几乎是全世界这个领域的事实性规范。
由于文章篇幅有限,本PDF面经不会全部发布在平台上面,所以需要完整资源的同学可以关注并私信我【消息队列】来免费获取!!!
问题二:如何保证消息队列的高可用?
面试官心理分析
如果有人问到你 MQ 的知识,高可用是必问的。上一讲提到,MQ 会导致系统可用性降低。所以只要你用了 MQ,接下来问的一些要点肯定就是围绕着 MQ 的那些缺点怎么来解决了。
要是你傻乎乎的就干用了一个 MQ,各种问题从来没考虑过,那你就杯具了,面试官对你的感觉就是,只会 简单使用一些技术,没任何思考,马上对你的印象就不太好了。这样的同学招进来要是做个 20k 薪资以内 的普通小弟还凑合,要是做薪资 20k+ 的高工,那就惨了,让你设计个系统,里面肯定一堆坑,出了事故公司受损失,团队一起背锅。
面试题剖析
这个问题这么问是很好的,因为不能问你 Kafka 的高可用性怎么保证?ActiveMQ 的高可用性怎么保证? 一个面试官要是这么问就显得很没水平,人家可能用的就是 RabbitMQ,没用过 Kafka,你上来问人家 Kafka 干什么?这不是摆明了刁难人么。
所以有水平的面试官,问的是 MQ 的高可用性怎么保证?这样就是你用过哪个 MQ,你就说说你对那个 MQ 的高可用性的理解。
RabbitMQ 的高可用性
RabbitMQ 是比较有代表性的,因为是 基于主从(非分布式) 做高可用性的,我们就以 RabbitMQ 为例子 讲解第一种 MQ 的高可用性怎么实现。
RabbitMQ 有三种模式:单机模式、普通集群模式、镜像集群模式。
单机模式
单机模式,就是 Demo 级别的,一般就是你本地启动了玩玩儿的
普通集群模式(无高可用性)
普通集群模式,意思就是在多台机器上启动多个 RabbitMQ 实例,每个机器启动一个。你创建的 queue
, 只会放在一个 RabbitMQ 实例上,但是每个实例都同步 queue
的元数据(元数据可以认为是 queue 的一 些配置信息,通过元数据,可以找到 queue 所在实例)。你消费的时候,实际上如果连接到了另外一个实例,那么那个实例会从 queue
所在实例上拉取数据过来。
这种方式确实很麻烦,也不怎么好, 没做到所谓的分布式,就是个普通集群。因为这导致你要么消费者每次 随机连接一个实例然后拉取数据,要么固定连接那个
queue
所在实例消费数据,前者有
数据拉取的开销, 后者导致
单实例性能瓶颈。
而且如果那个放 queue
的实例宕机了,会导致接下来其他实例就无法从那个实例拉取,如果你开启了消息持久化,让 RabbitMQ 落地存储消息的话,消息不一定会丢,得等这个实例恢复了,然后才可以继续从这 个 queue
拉取数据。
所以这个事儿就比较尴尬了,这就没有什么所谓的高可用性,这方案主要是提高吞吐量的,就是说让集群中 多个节点来服务某个 queue
的读写操作。
镜像集群模式(高可用性)
这种模式,才是所谓的 RabbitMQ 的高可用模式。跟普通集群模式不一样的是,在镜像集群模式下,你创建的 queue
,无论元数据还是 queue
里的消息都会存在于多个实例上,就是说,每个 RabbitMQ 节点都有这个 queue
的一个完整镜像,包含 queue
的全部数据的意思。然后每次你写消息到 queue
的时候,都 会自动把消息同步到多个实例的 queue
上。
那么如何开启这个 镜像集群模式呢?其实很简单, RabbitMQ 有很好的管理控制台,就是在后台新增一个策略,这个策略是 镜像集群模式的策略,指定的时候是可以要求数据同步到所有节点的,也可以要求同步到指定数量的节点,再次创建
queue
的时候,应用这个策略,就会自动将数据同步到其他的节点上去了。
这样的话,好处在于,你任何一个机器宕机了,没事儿,其它机器(节点)还包含了这个 queue
的完整数据,别的 consumer
都可以到其它节点上去消费数据。坏处在于,第一,这个性能开销也太大了吧,消息需要同步到所有机器上,导致网络带宽压力和消耗很重!第二,这么玩儿,不是分布式的,就没有扩展性可言了,如果某个 queue
负载很重,你加机器,新增的机器也包含了这个 queue
的所有数据,并没有办法线性扩展你的 queue
。你想,如果这个 queue
的数据量很大,大到这个机器上的容量无法容纳了,此时该怎么办呢?
Kafka 的高可用性
Kafka 一个最基本的架构认识:由多个
broker
组成,每个broker
是一个节点;你创建一个topic
,这 个topic
可以划分为多个partition
,每个partition
可以存在于不同的broker
上,每个partition
就放一部分数据。
这就是天然的分布式消息队列,就是说一个 topic
的数据,是分散放在多个机器上的,每个机器就放一部分数据。
实际上 RabbitMQ 之类的,并不是分布式消息队列,它就是传统的消息队列,只不过提供了一些集群、 HA(High Availability, 高可用性) 的机制而已,因为无论怎么玩儿,RabbitMQ 一个 queue
的数据都是放在一个节点里的,镜像集群下,也是每个节点都放这个 queue
的完整数据。
Kafka 0.8 以前,是没有 HA 机制的,就是任何一个 broker
宕机了,那个 broker
上的 partition
就废了,没法写也没法读,没有什么高可用性可言。
比如说,我们假设创建了一个 topic
,指定其 partition
数量是 3 个,分别在三台机器上。但是,如果 第二台机器宕机了,会导致这个 topic
的 1/3 的数据就丢了,因此这个是做不到高可用的。
Kafka 0.8 以后,提供了 HA 机制,就是 replica(复制品) 副本机制。每个
partition
的数据都会同步到其它机器上,形成自己的多个
replica
副本。所有
replica
会选举一个
leader
出来,那么生产和消费都跟这个
leader
打交道,然后其他
replica
就是
follower
。写的时候,
leader
会负责把数据同步到所有
follower
上去,读的时候就直接读
leader
上的数据即可。只能读写
leader
?很简单,要是你可以随意读写每个
follower
,那么就要
care
数据一致性的问题,系统复杂度太高,很容易出问题。
Kafka 会均匀地将一个
partition
的所有
replica
分布在不同的机器上,这样才可以提高容错性。
这么搞,就有所谓的 高可用性了,因为如果某个
broker
宕机了,没事儿,那个
broker
上面的
partition
在其他机器上都有副本的。如果这个宕机的
broker
上面有某个
partition
的
leader
,那么此时会从
follower
中
重新选举一个新的
leader
出来,大家继续读写那个新的
leader
即可。这就有所谓的高可用性了。
写数据的时候,生产者就写 leader
,然后 leader
将数据落地写本地磁盘,接着其他 follower
自己主动从 leader
来 pull
数据。一旦所有 follower
同步好数据了,就会发送 ack
给 leader
,leader
收到所有 follower
的 ack
之后,就会返回写成功的消息给生产者。(当然,这只是其中一种模式,还可以适当调整这个行为)
消费的时候,只会从 leader
去读,但是只有当一个消息已经被所有 follower
都同步成功返回 ack
的 时候,这个消息才会被消费者读到。
看到这里,相信你大致明白了 Kafka 是如何保证高可用机制的了,对吧?不至于一无所知,现场还能给面试官画画图。要是遇上面试官确实是 Kafka 高手,深挖了问,那你只能说不好意思,太深入的你没研究过。
由于文章篇幅有限,本PDF面经不会全部发布在平台上面,所以需要完整资源的同学可以关注并私信我【消息队列】免费获取!!!