消息队列activemq

消息队列activemq

首先，咱们为何须要消息队列？
其实就是问问你消息队列都有哪些使用场景，而后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？
面试官问你这个问题，指望的一个回答是说，大家公司有个什么业务场景，这个业务场景有个什么技术挑战，若是不用MQ可能会很麻烦，可是你如今用了MQ以后带给了你不少的好处！
先说一下消息队列的常见使用场景吧，其实场景有不少，可是比较核心的有3个：解耦、异步、削峰
1.解耦：现场画个图来讲明一下

A系统发送个数据到BCD三个系统，接口调用发送，那若是E系统也要这个数据呢？那若是C系统如今不须要了呢？如今A系统又要发送第二种数据了呢？A系统负责人濒临崩溃中。。。再来点更加崩溃的事儿，A系统要时时刻刻考虑BCDE四个系统若是挂了咋办？我要不要重发？我要不要把消息存起来？头发都白了啊。。。

面试技巧：你须要去考虑一下你负责的系统中是否有相似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。可是其实这个调用是不须要直接同步调用接口的，若是用MQ给他异步化解耦，也是能够的，你就须要去考虑在你的项目里，是否是能够运用这个MQ去进行系统的解耦。在简历中体现出来这块东西，用MQ做解耦。

2.异步：现场画个图来讲明一下，


A系统接收一个请求，须要在本身本地写库，还须要在BCD三个系统写库，本身本地写库要3ms，BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是3 + 300 + 450 + 200 = 953ms，接近1s，用户感受搞个什么东西，慢死了慢死了。
削峰：天天0点到11点，A系统风平浪静，每秒并发请求数量就100个。结果每次一到11点~1点，每秒并发请求数量忽然会暴增到1万条。可是系统最大的处理能力就只能是每秒钟处理1000个请求啊。。。尴尬了，系统会死。。。

消息队列有什么优势和缺点呢？
优势上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰。
缺点：看个图

系统可用性下降：系统引入的外部依赖越多，越容易挂掉，原本你就是A系统调用BCD三个系统的接口就行了，人ABCD四个系统好好的，没啥问题，你偏加个MQ进来，万一MQ挂了咋整？MQ挂了，整套系统崩溃了，你不就完了么。

系统复杂性提升：硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的状况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已

一致性问题：A系统处理完了直接返回成功了，人都觉得你这个请求就成功了；可是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。

因此消息队列实际是一种很是复杂的架构，你引入它有不少好处，可是也得针对它带来的坏处作各类额外的技术方案和架构来规避掉，最好以后，你会发现，妈呀，系统复杂度提高了一个数量级，也许是复杂了10倍。可是关键时刻，用，仍是得用的。。。

那么kafka、activemq、rabbitmq、rocketmq都有什么优势和缺点呢？
常见的MQ其实就这几种，别的还有不少其余MQ，可是比较冷门的，那么就别多说了

做为一个码农，你起码得知道各类mq的优势和缺点吧，我们来画个表格看看




综上所述，各类对比以后，我我的倾向因而：
1.通常的业务系统要引入MQ，最先你们都用ActiveMQ，可是如今确实你们用的很少了，没通过大规模吞吐量场景的验证，社区也不是很活跃，因此你们仍是算了吧，我我的不推荐用这个了；
2.后来你们开始用RabbitMQ，可是确实erlang语言阻止了大量的java工程师去深刻研究和掌控他，对公司而言，几乎处于不可控的状态，可是确实人是开源的，比较稳定的支持，活跃度也高；
3.不过如今确实愈来愈多的公司，会去用RocketMQ，确实很不错，可是我提醒一下本身想好社区万一忽然黄掉的风险，对本身公司技术实力有绝对自信的，我推荐用RocketMQ，不然回去老老实实用RabbitMQ吧，人是活跃开源社区，绝对不会黄。因此中小型公司，技术实力较为通常，技术挑战不是特别高，用RabbitMQ是不错的选择；大型公司，基础架构研发实力较强，用RocketMQ是很好的选择。
4.若是是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，况且几乎是全世界这个领域的事实性规范