博主有两位朋友分别是小A和小B:
小A，工作于传统软件行业(某社保局的软件外包公司)，每天工作内容就是和产品聊聊需求，改改业务逻辑。再不然就是和运营聊聊天，写几个SQL，生成下报表。又或者接到客服的通知，某某功能故障了，改改数据，然后下班部署上线。每天过的都是这种生活，技术零成长。
小B，工作于某国企，虽然能接触到一些中间件技术。然而，他只会订阅/发布消息。通俗点说，就是调调API。对为什么使用这些中间件啊？如何保证高可用啊？没有充分的认识。
庆幸的是两位朋友都很有上进心，于是博主写这篇文章，帮助他们复习一下关于消息队列中间件这块的要点
复习要点本文大概围绕如下几点进行阐述:
为什么使用消息队列？
使用消息队列有什么缺点?
消息队列如何选型?
如何保证消息队列是高可用的？
如何保证消息不被重复消费?
如何保证消费的可靠性传输?
如何保证消息的顺序性？
我们围绕以上七点进行阐述。需要说明一下，本文不是《消息队列从入门到精通》这种课程，因此只是提供一个复习思路，而不是去教你们怎么调用消息队列的API。建议对消息队列不了解的人，去找点消息队列的博客看看，再看本文，收获更大
正文 1、为什么要使用消息队列?分析:一个用消息队列的人，不知道为啥用，这就有点尴尬。没有复习这点，很容易被问蒙，然后就开始胡扯了。
回答:这个问题,咱只答三个最主要的应用场景(不可否认还有其他的，但是只答三个主要的),即以下六个字:解耦、异步、削峰
传统模式:
传统模式的缺点：
系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！
中间件模式:
中间件模式的的优点：
将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。
(2)异步传统模式:
传统模式的缺点：
一些非必要的业务逻辑以同步的方式运行，太耗费时间。
中间件模式:
中间件模式的的优点：
将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度
(3)削峰传统模式
传统模式的缺点：
并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常
中间件模式:
中间件模式的的优点：
系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。
2、使用了消息队列会有什么缺点?分析:一个使用了MQ的项目，如果连这个问题都没有考虑过，就把MQ引进去了，那就给自己的项目带来了风险。我们引入一个技术，要对这个技术的弊端有充分的认识，才能做好预防。要记住，不要给公司挖坑！
回答:回答也很容易，从以下两个个角度来答
系统可用性降低:你想啊，本来其他系统只要运行好好的，那你的系统就是正常的。现在你非要加个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性降低
系统复杂性增加:要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。因此，需要考虑的东西更多，系统复杂性增大。
但是，我们该用还是要用的。
3、消息队列如何选型?先说一下，博主只会ActiveMQ,RabbitMQ,RocketMQ,Kafka，对什么ZeroMQ等其他MQ没啥理解，因此只能基于这四种MQ给出回答。
分析:既然在项目中用了MQ，肯定事先要对业界流行的MQ进行调研，如果连每种MQ的优缺点都没了解清楚，就拍脑袋依据喜好，用了某种MQ，还是给项目挖坑。如果面试官问:"你为什么用这种MQ？。"你直接回答"领导决定的。"这种回答就很LOW了。还是那句话，不要给公司挖坑。
回答:首先，咱先上ActiveMQ的社区，看看该MQ的更新频率: