本文介绍了MQ（消息队列）在架构中的角色，强调其作为解耦利器的特性。讨论了不适合使用MQ的场景，如强依赖执行结果的情况，接着详细阐述了MQ在数据驱动任务、上游不关心执行结果、关注执行结果但执行时间长以及削峰填谷等典型场景的应用，展示了MQ如何优化系统性能和解耦。
系列文章是博主对沈剑的《架构师训练营》分享内容的个人笔记总结，原内容公众号“成为架构师”。
MQ是什么
MQ，消息队列，或者叫消息总线，常用于上下游之间消息通信的解耦。上游是一个消息发送进程，中间是MQ服务，下游是消息接收进程，上下游的消息进程往往不在一台服务器上。
消息的发送方不需要关注消息的接收方是谁，消息的接收方也不需要关注消息的发送方是谁，二者在物理和逻辑上都不依赖彼此。
不应该使用MQ的场景
在讲四个典型的使用场景之前，先来看不应该使用MQ的场景：当调用方密切关注执行结果的时候，应该使用RPC调用（或者Restfu接口调用），而不是使用MQ。
比如一个验证密码是否正确的登录服务：
根据用户输入密码的不同，会走不同的处理，返回不同的结果，这时候调用方是强依赖于密码服务的执行结果的。
绝大部分场景都是使用的RPC调用，如果硬要用MQ来处理的话：
登录请求要等待MQ的回调，执行过程缓慢，同时因为引入的消息中间件，使得编码变得复杂，
最低0.47元/天 解锁文章
2135
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
