理解消息队列

参考链接：https://www.zhihu.com/question/54152397

消息队列模型

MQ（Message Queue）的本质是发消息、存消息、取消息，三个行为对应生产者、队列、消费者三个实体。

队列模型下读消息的顺序与写入消息的顺序相同，而“读”消息则意味着消息出队，即被队列“删除”。

基于该模型我们可以假设，如果当前存在多个生产者，那么整个消息模型是不被打破的，多个生产者可以将数据发送到消息队列中，消费者照常从消息队列中获取消息。但是，如果该模型中存在多个消费者（这也是实际开发中经常遇到的业务场景），一条消息在被任一消费者接收后即出队，意味着其他的消费者无法从队列中获取到那条消息，可以看出上述模型是无法满足对所有消费者“一视同仁”的。

如果想要满足多个消费者都接收同一条消息，我们改造这个模型，给每个消费者一个队列，让生产者给每个队列都推送消息，这样是否可行呢？答案是：可以。

一定程度上这个方式可以满足我们的需求，但现实场景中几乎不会这么做，因为它增加了生产者发送消息的消耗、对消息队列的维护，并且假设消费者A不再需要接收消息，那么生产者也就不再需要给队列A发送消息，还是要修改生产者的代码，并不友好。

这就引出了另一种消息模型：发布订阅模型

发布订阅模型

发布订阅模型很好地解决了上述的多个消费者的业务场景。

在发布订阅模型中，多个订阅者对应同一个“主题”，如果订阅者需要这个主题的内容，可以主动订阅该主题，那么就可以接收到该主题的全部消息。模型中由主题来根据订阅决定一份消息是否需要被多次发送。

将两种模型做对比，不难看出消息队列模型更像是“单播”，即P2P（点到点）的；发布订阅模型则像是“广播”，即群发消息。那么很明显发布订阅模型完全可以实现P2P的效果。

应用场景

下述以常见的购物系统为例，介绍消息队列的使用场景。

用户在平台支付成功后，平台首先要生成订单，订单生成成功后需要根据这笔订单的信息来更新用户的积分、将订单通知到商家、根据订单内容更新用户画像、给用户发送短信确认下单成功，在真实业务场景中可能需要的操作会更多更复杂。

异步通信

基于该场景，结合我们日常购物的体验来思考，生成订单其实是很快的流程，如果用户在等待下单结果时系统响应耗费较大的时间，那其实是非常不合理的。同时我们可以发现，更新积分、通知商家、更新画像以及接收短信，对用户来说并不需要是绝对实时的，毕竟我们也几乎没有过先收到下单成功的短信消息，页面后返回下单成功的提示。

那么不难看出，生成订单之后的操作可以是异步的，在订单生成后直接返回给用户，这样就做到了最大程度的缩短用户等待时长。

流量削峰

消息队列还可以做负载的“漏斗”。

假设在流量高峰期每秒会有1w个请求，而消费者每秒只可以处理8k个，那么剩下的2k个就存放在消息队列中，下1w个请求进入到队列后，服务器就会处理第一次的2k个请求和第二次的8k个请求。在流量高峰期过去之后，消息队列的负载也会降下来。

系统解耦

上述的异步通信虽然使用线程池也可以实现，但针对这样的业务量，代码很难解耦，如果需要增加或删除一个步骤，都需要重新发布整个下单系统。

使用消息队列，下单后我们只需要将订单信息交给消息队列，如果增加/删除后续步骤，维护的都是其他的服务，不会影响到下单系统本身，这就是将额外服务与下单解耦。