mq:message queue,消息队列。
模式:发布-订阅模式。可以用来实现刷新商品。
基础认知：消费者、生产者、队列。消费者从队列消耗消息，生产者往队列发送消息。生产者和消费者互不干扰。
消息中间件：kafka、rabbitMQ，是业界内使用最广泛的消息中间件。
消息队列技术包含的元素：发布源、消息、消息中间件、队列、业务方（消费消息）。
消息的行走路线和状态：消息的发布源发布一条消息，消息抵达中间件就会被分发到对应的队列，此时消息进入就绪状态，接下来就看我们的消费者如何去拉取消息了。其实消费者就是我们的业务方，它会按照预定的配置从对应的队列中拉取消息。整个流程中，生产者和消费者是异步的，各干各的。
消息队列的使用场景：
1、跨系统异步通信。新老系统之间，只要使用同一套消息机制就可以进行通信。老系统没有像新系统一样使用了springcloud注册了，所以新系统无法向老系统发起调用，所以得依赖消息中间件。
2、解耦。订单支付之后，也就是下单完成后，订单的生命周期才刚刚开始，有履约配送服务、邮件发送服务，甚至，后续可能需要接入新的业务，购买返券的服务。最好的方式是，这三个业务订阅这个消息主题，订阅主题的意思也就是各个服务监听对应的主题（下单完成），消息抵达中间件，就会被下游服务监听到，那三个业务就会井然有序的执行，便实现了应用（订单、配送、邮件发送）间的解耦。相反，如果没有使用消息中间件，而是把配送、发送邮件、返券这三个业务和订单服务耦合在一起，会怎么样呢？订单服务的下单操作要持续挨个的调用其它服务，这对于上游服务的下单操作是一个很大的负担。此时再加入一个返券业务，下单操作便还要去接入饭券的业务，维护也相对麻烦。
3、流量削峰（降低单位时间内的流量，总流量不变，通过扩大处理时间来保证每个请求的执行）。1s内处理10w个下单请求，当前数量的集群也是处理不了的。短时间内的爆发流量应该被平滑地流入服务端。把10w的请求存储在消息中间件，集群下的各个服务端（就是消费者）依据自己的能力自主拉取请求并执行，每个节点接收到的请求都在自己的能力处理范围之内。
生产者和消费者共用一个topic，是否会暴雷？
