参考链接：https://www.zhihu.com/question/54152397
消息队列模型
MQ（Message Queue）的本质是发消息、存消息、取消息，三个行为对应生产者、队列、消费者三个实体。
队列模型下读消息的顺序与写入消息的顺序相同，而“读”消息则意味着消息出队，即被队列“删除”。
基于该模型我们可以假设，如果当前存在多个生产者，那么整个消息模型是不被打破的，多个生产者可以将数据发送到消息队列中，消费者照常从消息队列中获取消息。但是，如果该模型中存在多个消费者（这也是实际开发中经常遇到的业务场景），一条消息在被任一消费者接收后即出队，意味着其他的消费者无法从队列中获取到那条消息，可以看出上述模型是无法满足对所有消费者“一视同仁”的。
如果想要满足多个消费者都接收同一条消息，我们改造这个模型，给每个消费者一个队列，让生产者给每个队列都推送消息，这样是否可行呢？答案是：可以。
一定程度上这个方式可以满足我们的需求，但现实场景中几乎不会这么做，因为它增加了生产者发送消息的消耗、对消息队列的维护，并且假设消费者A不再需要接收消息，那么生产者也就不再需要给队列A发送消息，还是要修改生产者的代码，并不友好。
这就引出了另一种消息模型：发布订阅模型
发布订阅模型
发布订阅模型很好地解决了上述的多个消费者的业务场景。
在发布订阅模型中，多个订阅者对应同一个“主题”，如果订阅者需要这个主题的内容，可以主动订阅该主题，那么就可以接收到该主题的全部消息。模型中由主题来根据订阅决定一份消息是否需要被多次发送。
将两种模型做对比，不难看出消息队列模型更像是“单播”，即P2P（点到点）的；发布订阅模型则像是“广播”，即群发消息。那么很明显发布订阅模型完全可以实现P2P的效果。
应用场景
下述以常见的购物系统为例，介绍消息队列的使用场景。
用户在平台支付成功后，平台首先要生成订单，订单生成成功后需要根据这笔订单的信息来更新用户的积分、将订单通知到商家、根据订单内容更新用户画像、给用户发送短信确认下单成功，在真实业务场景中可能需要的操作会更多更复杂。
异步通信
基于该场景，结合我们日常购物的体验来思考，生成订单其实是很快的流程，如果用户在等待下单结果时系统响应耗费较大的时间，那其实是非常不合理的。同时我们可以发现，更新积分、通知商家、更新画像以及接收短信，对用户来说并不需要是绝对实时的，毕竟我们也几乎没有过先收到下单成功的短信消息，页面后返回下单成功的提示。
那么不难看出，生成订单之后的操作可以是异步的，在订单生成后直接返回给用户，这样就做到了最大程度的缩短用户等待时长。
流量削峰
消息队列还可以做负载的“漏斗”。
假设在流量高峰期每秒会有1w个请求，而消费者每秒只可以处理8k个，那么剩下的2k个就存放在消息队列中，下1w个请求进入到队列后，服务器就会处理第一次的2k个请求和第二次的8k个请求。在流量高峰期过去之后，消息队列的负载也会降下来。
系统解耦
上述的异步通信虽然使用线程池也可以实现，但针对这样的业务量，代码很难解耦，如果需要增加或删除一个步骤，都需要重新发布整个下单系统。
使用消息队列，下单后我们只需要将订单信息交给消息队列，如果增加/删除后续步骤，维护的都是其他的服务，不会影响到下单系统本身，这就是将额外服务与下单解耦。
标签：订阅,消费者,队列,模型,理解,消息,下单 来源： https://blog.csdn.net/weixin_44490757/article/details/120570065
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。