一.什么是消息队列

两个客户端A、B，A给B直接发送数据，必须保证同步（比如B挂了或者A发送数据10Mbps，B接收数据5Mbps,丢数据）为了解决同步问题，使用消息队列作为A和B之间的一个缓存。A将数据发送给消息队列，B只要正常就去队列中拿数据，这样就可以异步处理数据发送与接收的问题。

消息队列分为点对点模式和发布订阅模式

点对点模式：（一对一，消费者主动拉取数据，消息收到后消息清除）

点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是队列将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。

优点：消费者主动拉取数据，拉取速度取决于消费者自身

缺点：必须有一个线程来实施监控消息队列中是否有数据

发布订阅模式：（一对多，数据生产后，推送给所有订阅者）

发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。优缺点和点对点模式正好对应，优点是基于推送，有消息才会推送给消费者，缺点是消息传输速度取决于推送速度，若速度大于消费者消费的速度，会造成消息积压。

二.为什么需要消息队列

1.异步

很好理解，以一个订单流程为例：

下单

下单过程很复杂，用户从付款以后要经过很多个步骤，如果你一路串行等着每个步骤都执行完再告诉用户你买好了，用户肯定是不干。其实完全不必要这么做，只需下单完成支付，就可以告诉用户购买成功了，其他的业务可以异步执行，因为用户只想最快的要一个结果，你优惠券、短信、积分，晚个几分钟其实都没太大所谓，况且也不会这么慢

异步

2.解耦

有人会说，我不异步，我起一个线程池，用多线程去跑这个业务。ok，可以，但是你想想，一个流程，每个任务都得对应一个接口，当需要新加一个流程，你就新写一个接口，然后再去改线程的任务，而且全部写在一起，出了问题很不容易排查，随便哪个任务出点问题就会影响全局（前几天刚搞了一个多线程bug，傻逼兮兮的全部try catch，出了问题都监控不到）

解耦

下单完成，就把这个消息发送给其他系统，让他们自己处理就ok，你只管自己的流程就好。消费者去消息队列中获取支付成功的消息，这样就把一个订单流程所有的业务都拆分成一个个相互独立的系统，不再依赖，靠消息对请求进行异步处理。

3.削峰

把请求放到消息队列，等到流量高峰，我就允许一定数量的请求被处理，可以进入队列，剩下的直接扔回去给个友好提示。

问题

消息队列的高可用、重复消费、消息丢失、消息顺序、分布式事务