什么是MQ？

MessageQueue:就是消息 + 队列，任务+队列，指令 + 队列。
功能：应用程序之间（生产者与消费者）的通信方式。

使用场景

从下面这个场景来感受MQ 的诞生
如果我们有很多任务需要处理，任务会不停的发送过来，我们需要进行处理，没有MQ我们就普通开发这个功能可能会有下面这几种思路

1. 单线程
2. 单线程 + 单队列
3. 多线程 + 单队列
4. 多线程 + 多队列
   
   从上面的例子其实我们可以有下面这几个思考：
   1）我们使用队列排队的方式，是不是其实任务处理的实时性没有那么高呢？是不是其实是异步处理。那么比如有这样一个例子，用户注册。注册完自动登录，但是这个系统比较复杂，比如需要向用户发送短信欢迎用户成为一员，又如积分制度，或者针对新用户有一些优惠卷或者其它特权。如果系统够大，一般肯定积分系统和优惠卷系统都会作为一个独立的模块，那用户在注册这个动作的时候需要关心这些吗？其实不需要，先只完成核心的注册逻辑，这些附加的功能就可以进行异步处理，比如我们把初始化积分和优惠卷赠送这样的任务进行异步处理分别向积分系统和优惠卷系统发送一个消息，当前我们完成用户系统的信息初始化后就立即响应用户，这样对用户来说体验是很好的, 也能提升系统的QPS。
   2）那基于1的思考，我们拆分成了不同的系统，向不同的系统发送消息，这个时候其实MQ充当一个通信的角色。那这些不同的系统是不是被解耦了呢？同时是不是可以通过主系统向不同的系统分发数据呢。

其实我们我们上面的思考远远不够，比如消息如果不持久化岂不是服务重启后就没有了吗，任务处理过程中发生异常怎么办，怎么路由到不同的队列，如果我们有点对点的处理或广播处理这种需求呢。那么MQ就是解决了这些问题的一个方案，MQ考虑的比我们更多，也提供了不同问题的解决方式。

基于上面的一些简单的思考我们可以总结出MQ的应用场景：

• 异步：侧重的处理流程，流程上将以前的一些同步逻辑，改造成为异步的逻辑流程。
• 解耦：侧重的功能设计，在做一些业务架构分析的时候，可以有力度有重点的区分主干流程、分支流程。
• 削峰限流：侧重在数量级的问题，相比于未接入MQ时能再次抗上几倍甚至几十倍、几百倍…的流量。
• 延迟调用（准实时、一定延时）：侧重定制化诉求，在 db 与 MQ 之间做了一个抉择。

MQ的选择

Rocketmq官方网网
Why choose RocketMQ 有个各个MQ的对比。
那么我们在选型的时候需要考虑不同的维度，这些维度可以参考下面这张图
图片来源：https://time.geekbang.org/column/article/540810