江苏龙网

  1. 首页 > 资讯 > 科技 > >

|阿里面试问消息队列MQ，原来是这么回答的( 二 )



如果使用 MQ ， 每秒 5k 个请求写入 MQ ， A 系统每秒钟最多处理 2k 个请求 ， 因为 MySQL 每秒钟最多处理 2k 个 。 A 系统从 MQ 中慢慢拉取请求 ， 每秒钟就拉取 2k 个请求 ， 不要超过自己每秒能处理的最大请求数量就 ok ， 这样下来 ， 哪怕是高峰期的时候 ， A 系统也绝对不会挂掉 。 而 MQ 每秒钟 5k 个请求进来 ， 就 2k 个请求出去 ， 结果就导致在中午高峰期（1 个小时） ， 可能有几十万甚至几百万的请求积压在 MQ 中 。
|阿里面试问消息队列MQ，原来是这么回答的
本文插图

这个短暂的高峰期积压是 ok 的 ， 因为高峰期过了之后 ， 每秒钟就 50 个请求进 MQ ， 但是 A 系统依然会按照每秒 2k 个请求的速度在处理 。 所以说 ， 只要高峰期一过 ， A 系统就会快速将积压的消息给解决掉 。
2. 消息队列有什么优缺点
优点上面已经说了 ， 就是在特殊场景下有其对应的好处 ， 解耦、异步、削峰 。
缺点有以下几个：
1.系统可用性降低 系统引入的外部依赖越多 ， 越容易挂掉 。 本来你就是 A 系统调用 BCD 三个系统的接口就好了 ， 人 ABCD 四个系统好好的 ， 没啥问题 ， 你偏加个 MQ 进来 ， 万一 MQ 挂了咋整 ， MQ 一挂 ， 整套系统崩溃的 ， 你不就完了？
2.系统复杂度提高 硬生生加个 MQ 进来 ， 你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大 ， 问题一大堆 ， 痛苦不已 。
3.一致性问题 A 系统处理完了直接返回成功了 ， 人都以为你这个请求就成功了；但是问题是 ， 要是 BCD 三个系统那里 ， BD 两个系统写库成功了 ， 结果 C 系统写库失败了 ， 咋整？你这数据就不一致了 。
所以消息队列实际是一种非常复杂的架构 ， 你引入它有很多好处 ， 但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉 ， 做好之后 ， 你会发现 ， 妈呀 ， 系统复杂度提升了一个数量级 ， 也许是复杂了 10 倍 。 但是关键时刻 ， 用 ， 还是得用的 。
3.Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？选择建议？
|阿里面试问消息队列MQ，原来是这么回答的
本文插图
【|阿里面试问消息队列MQ，原来是这么回答的】

后来大家开始用 RabbitMQ ， 但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它 ， 对公司而言 ， 几乎处于不可控的状态 ， 但是确实人家是开源的 ， 比较稳定的支持 ， 活跃度也高；
不过现在确实越来越多的公司 ， 会去用 RocketMQ ， 确实很不错（阿里出品） ， 但社区可能有突然黄掉的风险 ， 对自己公司技术实力有绝对自信的 ， 推荐用 RocketMQ ， 否则回去老老实实用 RabbitMQ 吧 ， 人家有活跃的开源社区 ， 绝对不会黄 。
所以中小型公司 ， 技术实力较为一般 ， 技术挑战不是特别高 ， 用 RabbitMQ 是不错的选择；大型公司 ， 基础架构研发实力较强 ， 用 RocketMQ 是很好的选择 。
如果是大数据领域的实时计算、日志采集等场景 ， 用 Kafka 是业内标准的 ， 绝对没问题 ， 社区活跃度很高 ， 绝对不会黄 ， 何况几乎是全世界这个领域的事实性规范 。
Rocketmq Qps量级在10W左右 ， Rabbitmq在万级别 ， Rocketmq是经过双十一考验的 。
作者：风洛链接：https://juejin.im/post/5f004850e51d4534bb149bff


推荐阅读


上一篇：科技说说|胜负已定？小米高管“挖苦”华为硬件没优势了，明年只能靠营销

下一篇：驱动中国|快手与麦当劳推出“72小时满分叫醒”直播，全天不限时供应“麦满分”早餐