做java开发的面试基本会遇到java基础知识，设计模式，多线程，io，集合等，spring/springMvc/mybatis/springBoot，mysql/oracle/sql优化这些。现在仅仅会这些是不够的，还会要求缓存、消息队列、消息中间件。springCloud/Dubbo等分布式架构。。。等等，好多的同学可能没搞过那些东西，或者之前自己看过一些，知道点demo和概念，略知一二，就是面试的时候容易被面试官几个连环炮打蒙，然后面试就挂了，所以我们需要集中分析一下这些技术。这里我们先来分析一下消息队列。
我们先提出几个问题：
- 为什么使用消息队列啊？
- 用消息队列都有什么优点和缺点？
- kafka、activemq、rabbitmq、rocketmq都有什么区别？
- 如何保证消息队列的高可用啊？
- 如何保证消息不被重复消费啊？如何保证消费的时候是幂等的啊？
- 如何保证消息的可靠性传输啊？要是消息丢失了怎么办啊？
- 那如何保证消息的顺序性？
- 如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，怎么解决？
- 如果让你写一个消息队列，该如何进行架构设计啊？
消息队列比较核心的有3个：解耦、异步、削峰
解耦：现场画个图来说明一下，A系统发送个数据到BCD三个系统，接口调用发送，那如果E系统也要这个数据呢？那如果C系统现在不需要了呢？现在A系统又要发送第二种数据了呢？A系统负责人濒临崩溃中。。。再来点更加崩溃的事儿，A系统要时时刻刻考虑BCDE四个系统如果挂了咋办？我要不要重发？我要不要把消息存起来？头发都白了啊。。。
不用解耦的时候：
使用消息队列的情况：
以上就是解耦的效果，相信大家都能理解，接下来我们来看看
异步：现场画个图来说明一下，A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库，自己本地写库要3ms，BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是3 + 300 + 450 + 200 = 953ms，接近1s，用户感觉搞个什么东西，慢死了慢死了。
一般的情况：
使用消息队列后的情况：
通过比较我们可以清楚的感觉到两种情况的差异。
削峰：每天0点到11点，A系统风平浪静，每秒并发请求数量就100个。结果每次一到11点~1点，每秒并发请求数量突然会暴增到1万条。但是系统最大的处理能力就只能是每秒钟处理1000个请求啊。。。尴尬了，系统会死。。。
使用MQ以后的情况：
优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰
缺点呢？显而易见的
- 系统可用性降低：系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好了，人ABCD四个系统好好的，没啥问题，你偏加个MQ进来，万一MQ挂了咋整？MQ挂了，整套系统崩溃了，你不就完了么。
- 系统复杂性提高：硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已
- 一致性问题：A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。
所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，最好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了10倍。但是关键时刻，用，还是得用的。。。
kafka、activemq、rabbitmq、rocketmq都有什么优点和缺点啊？
通过分析我得出以下结论：
- 所以中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择；
- 大型公司，基础架构研发实力较强，用RocketMQ是很好的选择；
- 如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题。