MQ 使用场景

解耦

系统间接口调用进行解耦。
​
例如:
A系统需要给B、C、D三个系统进行数据推送，那么需要在代码中维护推送接口，并且要考虑到所推送系统宕机的情况，此时对于数据该如何处理，同时如果需要新增推送的系统，那么A系统中需要新增推送接口，或者某一个系统不需要接收数据，A系统还需要进行代码维护。
​
当加入MQ消息中间件时，A系统只需要将推送的数据发到MQ消息队列中即可，BCD三个系统可以自己从MQ中获取消息数据，并且可以自己控制是否需要去MQ消费数据，宕机也可以重新消费数据。

异步

减少接口响应时间
​
例如:
A系统需要在接到请求后给A、B、C、D系统系统进行数据落库，那么A系统接口的响应时间就是A+B+C+D的响应时间总和，对于用户来说，此时的响应时间已经是可以感知到的了，用户体验差。
​
当加入MQ时，A系统可以处理自己系统的数据落库，同时将落库的操作发到MQ，那么BCD三个系统就可以同时消费消息并进行数据落库，此时的响应时间就变成了A+发送到MQ的时间，大大减少了响应时间。
​

削峰

流量削峰，减少数据库的压力
​
例如:
A系统在上午，下午，晚上这三个时间段的并发并不高，几十上百的样子，但是到了正午，并发会突然急剧增加，并发大概会到5k，若此时大量数据进来系统并对数据库进行操作，数据库是无法承受这么大的并发量的，数据库最大的并发量也就2k，此时系统的风险时非常大的。
​
当加入MQ时，用户请求会先进MQ，MQ是可以承受5k并发的，后端会从MQ中每秒拉取2k个请求，那么此时就算是正午，数据库的压力也不至于直接宕机，当然MQ会在短时间内积压很多请求，但是一旦过了正午，积压的请求也会很快被拉取完。

造成的影响

1、系统可用性降低，若MQ挂掉，那么与它相关的所有系统都会瘫痪，此时则需要考虑MQ的高可用性。
​
2、系统复杂度提升，关于如何判断消息是否被重复消费过，消息的顺序性，消息丢失如何处理。
​
3、数据一致性问题，A系统落库成功后并将消息发送至MQ，但是BC系统并没有成功将数据落库，此时数据便不一致了。