Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
晶之木
advanced-java
提交
390cb1c1
A
advanced-java
项目概览
晶之木
/
advanced-java
与 Fork 源项目一致
从无法访问的项目Fork
通知
3
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
A
advanced-java
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
前往新版Gitcode,体验更适合开发者的 AI 搜索 >>
提交
390cb1c1
编写于
10月 07, 2018
作者:
Y
yanglbme
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Update why-mq.md
上级
12e74006
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
11 addition
and
9 deletion
+11
-9
docs/high-concurrency/why-mq.md
docs/high-concurrency/why-mq.md
+11
-9
未找到文件。
docs/high-concurrency/why-mq.md
浏览文件 @
390cb1c1
## 面试题
为什么使用消息队列?消息队列有什么优点和缺点?Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别,以及适合哪些场景?
-
为什么使用消息队列?
-
消息队列有什么优点和缺点?
-
Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别,以及适合哪些场景?
## 面试官心理分析
其实面试官主要是想看看:
...
...
@@ -11,8 +13,8 @@
-
**第二**
,你既然用了消息队列这个东西,你知不知道用了有什么好处&坏处?
<br>
你要是没考虑过这个,那你盲目弄个 MQ 进系统里,后面出了问题你是不是就自己溜了给公司留坑?你要是没考虑过引入一个技术可能存在的弊端和风险,面试官把这类候选人招进来了,基本可能就是挖坑型选手。就怕你干 1 年挖一堆坑,自己跳槽了,给公司留下无穷后患。
-
**第三**
,既然你用了 MQ
,
可能是某一种 MQ,那么你当时做没做过调研?
<br>
你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个 MQ,比
Kafka。甚至都从没调研过业界到底流行的 MQ 有哪几种?每一个MQ的优点和缺点是什么?
每一个 MQ
**没有绝对的好坏**
,但是就是看用在哪个场景可以
**扬长避短,利用其优势,规避其劣势**
。
<br>
-
**第三**
,既然你用了 MQ
,
可能是某一种 MQ,那么你当时做没做过调研?
<br>
你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个 MQ,比
如 Kafka,甚至都从没调研过业界流行的 MQ 到底有哪几种。每一个 MQ 的优点和缺点是什么。
每一个 MQ
**没有绝对的好坏**
,但是就是看用在哪个场景可以
**扬长避短,利用其优势,规避其劣势**
。
<br>
如果是一个不考虑技术选型的候选人招进了团队,面试官交给他一个任务,去设计个什么系统,他在里面用一些技术,可能都没考虑过选型,最后选的技术可能并不一定合适,一样是留坑。
## 面试题剖析
...
...
@@ -39,11 +41,11 @@
**面试技巧**
:你需要去考虑一下你负责的系统中是否有类似的场景,就是一个系统或者一个模块,调用了多个系统或者模块,互相之间的调用很复杂,维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的,如果用 MQ 给它异步化解耦,也是可以的,你就需要去考虑在你的项目里,是不是可以运用这个 MQ 去进行系统的解耦。在简历中体现出来这块东西,用 MQ 作解耦。
#### 异步
再来看一个场景,A 系统接收一个请求,需要在自己本地写库,还需要在 BCD 三个系统写库,自己本地写库要 3ms,BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms,接近 1s,用户感觉搞个什么东西,慢死了慢死了。用户通过浏览器发起请求,等待个 1s
中
,这几乎是不可接受的。
再来看一个场景,A 系统接收一个请求,需要在自己本地写库,还需要在 BCD 三个系统写库,自己本地写库要 3ms,BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms,接近 1s,用户感觉搞个什么东西,慢死了慢死了。用户通过浏览器发起请求,等待个 1s,这几乎是不可接受的。
![
mq-3
](
http://p9ucdlghd.bkt.clouddn.com/mq-3.png
)
一般互联网类的企业,对
用户的的
直接的操作,一般要求是每个请求都必须在 200 ms 以内完成,对用户几乎是无感知的。
一般互联网类的企业,对
于用户
直接的操作,一般要求是每个请求都必须在 200 ms 以内完成,对用户几乎是无感知的。
如果
**使用 MQ**
,那么 A 系统连续发送 3 条消息到 MQ 队列中,假如耗时 5ms,A 系统从接受一个请求到返回响应给用户,总时长是 3 + 5 = 8ms,对于用户而言,其实感觉上就是点个按钮,8ms 以后就直接返回了,爽!网站做得真好,真快!
...
...
@@ -58,7 +60,7 @@
![
mq-5
](
http://p9ucdlghd.bkt.clouddn.com/mq-5.png
)
如果使用 MQ,每秒 5k 个请求写入 MQ,A 系统每秒钟最多处理 2k 个请求,因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉
去请求,每秒钟就拉取 2k 个请求,不要超过自己每秒能处理的最大请求数量就 ok,这样下来,哪怕是高峰期的时候,A 系统也绝对不会挂掉。而MQ 每秒钟 5k 个请求进来,结果
就 2k 个请求出去,结果就导致在中午高峰期(1 个小时),可能有几十万甚至几百万的请求积压在 MQ 中。
如果使用 MQ,每秒 5k 个请求写入 MQ,A 系统每秒钟最多处理 2k 个请求,因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉
取请求,每秒钟就拉取 2k 个请求,不要超过自己每秒能处理的最大请求数量就 ok,这样下来,哪怕是高峰期的时候,A 系统也绝对不会挂掉。而MQ 每秒钟 5k 个请求进来,
就 2k 个请求出去,结果就导致在中午高峰期(1 个小时),可能有几十万甚至几百万的请求积压在 MQ 中。
![
mq-6
](
http://p9ucdlghd.bkt.clouddn.com/mq-6.png
)
...
...
@@ -78,7 +80,7 @@
-
一致性问题
<br>
A 系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是,要是 BCD 三个系统那里,BD 两个系统写库成功了,结果 C 系统写库失败了,咋整?你这数据就不一致了。
所以消息队列实际是一种非常复杂的架构,你引入它有很多好处,但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉,
最
好之后,你会发现,妈呀,系统复杂度提升了一个数量级,也许是复杂了 10 倍。但是关键时刻,用,还是得用的。
所以消息队列实际是一种非常复杂的架构,你引入它有很多好处,但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉,
做
好之后,你会发现,妈呀,系统复杂度提升了一个数量级,也许是复杂了 10 倍。但是关键时刻,用,还是得用的。
### Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点?
...
...
@@ -98,8 +100,8 @@ A 系统处理完了直接返回成功了,人都以为你这个请求就成功
后来大家开始用 RabbitMQ,但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它,对公司而言,几乎处于不可控的状态,但是确实人家是开源的,比较稳定的支持,活跃度也高;
不过现在确实越来越多的公司,会去用 RocketMQ
,确实很不错,但是我提醒一下自己想好社区万一
突然黄掉的风险,对自己公司技术实力有绝对自信的,我推荐用 RocketMQ,否则回去老老实实用 RabbitMQ 吧,人家有活跃的开源社区,绝对不会黄。
不过现在确实越来越多的公司,会去用 RocketMQ
(阿里出品),确实很不错,但社区可能有
突然黄掉的风险,对自己公司技术实力有绝对自信的,我推荐用 RocketMQ,否则回去老老实实用 RabbitMQ 吧,人家有活跃的开源社区,绝对不会黄。
所以
**中小型公司**
,技术实力较为一般,技术挑战不是特别高,用RabbitMQ 是不错的选择;
**大型公司**
,基础架构研发实力较强,用 RocketMQ 是很好的选择。
如果是大数据领域的实时计算、日志采集等场景,用 Kafka 是业内标准的,绝对没问题,社区活跃度很高,绝对不会黄,何况几乎是全世界这个领域的事实性规范。
\ No newline at end of file
如果是
**大数据领域**
的实时计算、日志采集等场景,用 Kafka 是业内标准的,绝对没问题,社区活跃度很高,绝对不会黄,何况几乎是全世界这个领域的事实性规范。
\ No newline at end of file
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录