对于使用动静队列明天被面试官问倒了

寂寞恋人

为何使用动静队列
其实就是问问你动静队列都有哪些使用场景，而后你名目里详细是甚么场景，说说你在这个场景里用动静队列是甚么？ 面试官问你这个问题，冀望的一个回答是说，你们公司有个甚么业务场景，这个业务场景有个甚么技术应战，假如不必 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 到 十二:00，A 零碎惊涛骇浪，每秒并发申请数量就 50 个。
后果每次一到 十二: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 个申请，不要超过本人每秒能处置的最大申请数量就 足够了。
这样上去，哪怕是顶峰期的时分，A 零碎也绝对不会挂掉。
而MQ 每秒钟 5k 个申请进来，就 2k 个申请出去，后果就致使在中午顶峰期（1 个小时），可能有几十万乃至几百万的申请积存在 MQ 中。



这个长久的顶峰期积存是可以接纳的，由于顶峰期过了之后，每秒钟就 50 个申请进 MQ，然而 A 零碎仍然会根据每秒 2k 个申请的速度在处置。
所以说，只有顶峰期一过，A 零碎就会疾速将积存的动静给解决掉。
动静队列有甚么优缺陷
优点就是在特殊场景下有其对应的益处，解耦、异步、削峰。缺陷有下列几个：
零碎可用性升高零碎引入的内部依赖越多，越容易挂掉。原本你就是 A 零碎调用 BCD 三个零碎的接口就行-了，ABCD 四个零碎还好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了怎么办MQ 一挂，整套零碎解体，不就完了。这时候便泛起了包管动静队列的高可用。零碎繁杂度进步硬生生加个 MQ 进来，怎么包管动静没有反复消费？如何处置动静丧失的状况？怎么包管动静传递的程序性？统一性问题A 零碎处置完了间接前往胜利了，人都认为你这个申请就胜利了；然而问题是，要是 BCD 三个零碎那里，BD 两个零碎写库胜利了，后果 C 零碎写库失败了，怎么办？数据就纷歧致了。所以动静队列实际是一种十分繁杂的架构，你引入它有得多益处，然而也得针对它带来的害处做各种额定的技术计划和架构来规避掉，做好之后会发现零碎繁杂度晋升了一个数量级，或许是繁杂了 10 倍。然而症结时辰，用仍是得用的。Kafka、ActiveMQ、RabbitMQ、RocketMQ 有甚么优缺陷特性
ActiveMQ
RabbitMQ
RocketMQ
Kafka
单机吞吐量
万级，比 RocketMQ、Kafka 低一个数量级
同 ActiveMQ
10 万级，撑持高吞吐
10 万级，高吞吐，个别配合大数据类的零碎来进行实时数据计算、日志收集等场景
topic 数量对吞吐量的影响
topic 能够达到几百/几千的级别，吞吐量会有较小幅度的降落，这是 RocketMQ 的一大劣势，在等同机器下，能够撑持少量的 topic
topic 从几十到几百个时分，吞吐量会大幅度降落，在等同机器下，Kafka 尽可能包管 topic 数量不要过量，假如要撑持大范围的 topic，需求减少更多的机器资源
时效性
ms 级
微秒级，这是 RabbitMQ 的一大特征，提早最低
ms 级
提早在 ms 级之内
可用性
高，基于主从架构完成高可用
同 ActiveMQ
十分高，散布式架构
十分高，散布式，一个数据多个正本，多数机器宕机，不会丧失数据，不会致使不成用
动静牢靠性
有较低的几率丧失数据
根本不丢
通过参数优化配置，能够做到 0 丧失
同 RocketMQ
功用反对
MQ 畛域的功用极为齐备
基于 erlang 开发，并发才能很强，机能极好，延时很低
MQ 功用较为完美，仍是散布式的，扩展性好
功用较为简略，次要反对简略的 MQ 功用，在大数据畛域的实时计算以及日志收集被大范围使用
综上，各种比较之后，能够发现：
个别的业务零碎要引入 MQ，最先大家都用 ActiveMQ，然而当初的确大家用的未几了，没通过大范围吞吐量场景的验证，社区也不是很活泼。
起初大家开始用 RabbitMQ，然而的确 erlang 言语禁止了少量的 Java 工程师去深化钻研和掌控它，对公司而言，简直处于不成控的形态，然而是开源的，对比不乱的反对，活泼度也高。
不外当初的确愈来愈多的公司会去用 RocketMQ，的确很不错，毕竟是阿里出品。
所以中小型公司，技术实力较为个别，技术应战不是特别高，用 RabbitMQ 是不错的选择；
大型公司，根底架构研发实力较强，用 RocketMQ 是很好的选择。
假如是大数据畛域的实时计算、日志收集等场景，用 Kafka 是业内规范的，绝对没问题，社区活泼度很高，绝对不会黄，何况简直是全世界这个畛域的事实性标准。
作者：啵啵肠 链接：http://juejin.cn/post/7196889066830708792 来源：稀土掘金