在互联网架构中,MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通知服务。
什么时候不使用MQ？
上游实时关注执行结果，通常采用RPC。
什么时候使用MQ？
（1）数据驱动的任务依赖。
（2）上游不关心执行结果。
（3）上游关注结果，但执行时间很长。
（4）削峰填谷，流量控制，保护下游
场景1：不适宜用MQ通信
图（1）MQ通信
图（2）RPC调用
如上图（1）所示，登录页面调用passport服务，会根据passport服务的返回结果，区别执行登录成功，登录失败，执行错误。调用方关注执行结果时，不宜使用MQ通讯。
使用MQ通讯，调用方不能直接告之用户登录成功又或失败，阻塞住等待MQ通知回调不但使得编码复杂，还会引入消息丢失的风险，中间多加入一层，多此一举，基本没有人这么玩。
MQ的不足：
（1）系统更复杂，多了MQ组件
（2）消息传递路径长，延时会增加
（3）消息可靠性和重复性相互矛盾，消息的不丢不重难以保证
（4）上游无法知道下游执行结果，这一点很致命
场景2：如果调用方不关心执行结果，却仍然使用RPC调用，会引发上下游极大的耦合与瓶颈。
耦合范围： 上游服务？what,一万个策马奔腾消息通知耦合：每每在心里怒骂“MD 明明是业务变更 为什么要改通用模块”
如上图：有一个上游服务upper，例如：“帖子发布中心”服务。负责产品通用的帖子发布业务。有些个性化的业务关心帖子发布事件，例如
- 下游服务biz1：用户发布帖子后，大数据部门要更新用户的画像
- 下游服务biz2：用户发布帖子后，信息质量部门要异步检查帖子是否合规
- 下游服务biz3：招聘业务最近在做用户促活，如果用户发布的是招聘帖子，要增加积分
- …
个性化下游关注这个事件，但下游对事件的执行结果，“帖子发布”服务却并不关心，如果“帖子发布”服务通过RPC的方式去通知下游，就会有很大的问题。
耦合为何存在？
帖子发布服务，这本来应该是一个非常基础的服务，上游upper通过RPC调用将事件同步给事件关注业务方biz1/biz2/biz3：
（1）一旦有新的业务需求要关注这个事件，修改代码的是通用上游upper，此时通用服务的owner就在心里骂娘了“为何有需求的是你，修改代码的却是我”
（2）一旦业务侧出问题，会影响上游通用基础服务，此时通用服务的owner又在心里骂娘了“我ca，稳定性的KPI，全被兄弟部门毁了”
（3）一旦业务侧接口升级，上游基础服务需要配合升级，此时通用服务的owner可能又会抱怨“为何被动升级的人总是我”
架构不合理，简直痛不欲生。
如何解耦呢？
如果事件发出方不关心订阅方的执行结果，不能用RPC，应该用MQ。
MQ能够做到上下游物理上和逻辑上都解耦：
- 物理上解耦，增加MQ之后，上游互不知道彼此的存在，不会建立物理连接了，大家都只与MQ建立物理连接
- 逻辑上解耦，事件发布方甚至不用知道哪些下游订阅了这个消息，新增消息的订阅方只需要连接MQ就行了，不需要上游关注
用MQ解耦的好处：
- 上游执行时间短，它只需要向MQ发送一个异步的消息即可
- 上下游没有物理、逻辑上的依赖关系
- 下游只需要向MQ订阅上游的执行成功消息即可，增减下游上游都不要关心
一篇架构知识，每天进度一点点
面试方法论：
1. cap理论
CAP理论指的是一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
结论：CAP三个特性肯定是不能同时满足的，但是可以满足其中两个。要么满足CP要么满足AP。
我们分析一下既然可以满足两个，那么舍弃哪一个比较好呢？
（1）满足CA舍弃P，也就是满足一致性和可用性，舍弃容错性。但是这也就意味着你的系统不是分布式的了，因为涉及分布式的想法就是把功能分开，部署到不同的机器上。（既然是分布式，这就不可取了！！！）
（2）满足CP舍弃A，也就是满足一致性和容错性，舍弃可用性。如果你的系统允许有段时间的访问失效等问题，这个是可以满足的。就好比多个人并发买票，后台网络出现故障，你买的时候系统就崩溃了。
（3）满足AP舍弃C，也就是满足可用性和容错性，舍弃一致性。这也就是意味着你的系统在并发访问的时候可能会出现数据不一致的情况。
实时证明，大多数都是牺牲了一致性。像12306还有淘宝网，就好比是你买火车票，本来你看到的是还有一张票，其实在这个时刻已经被买走了，你填好了信息准备买的时候发现系统提示你没票了。这就是牺牲了一致性。
但是不是说牺牲一致性一定是最好的。就好比mysql中的事务机制，张三给李四转了100块钱，这时候必须保证张三的账户上少了100，李四的账户多了100。因此需要数据的一致性，而且什么时候转钱都可以，也需要可用性。但是可以转钱失败是可以允许的。
