MQ消息队列详解

MQ的使用场景有很多，但是比较核心的就是：解耦、异步、削峰。

解耦

比如现在我们有ABCDE五个系统，最初的时候有BCD三个系统调用着A的接口。这时，D系统突然说不需要调用A的接口了，A系统只能删除调用D系统的代码；但A系统还没删除完时，E系统突然要调用A的接口，可A还未处理完D系统的请求，这时就会出现问题。

使用MQ之后，A系统的数据只需要放到MQ里面，其他的系统想请求获取数据只需要去MQ里面消费即可，如果突然不想请求了，就取消对MQ的消费就行了，A系统根本不需要考虑给谁去响应这个数据，也不需要去维护代码，也不用考虑其他系统是否调用成功，失败超时等情况。

异步调用

ABCD四个系统，A系统收到一个请求，需要在自己本地写库，还需要往BCD三个系统写库，A系统自己写本地库需要3ms，往其他系统写库相对较慢，B系统100ms ，C系统200ms，D系统300ms，这样算起来，整个功能从请求到响应的时间为3ms+100ms+200ms+300ms=603ms，接近一秒，对于用户来说，点个按钮要等这么长时间，基本是无法接受的，

但如果加入MQ，A系统只需要将三条消息发送到MQ中，假如需要花费5ms，整个功能 从请求到响应的时间为3ms+5ms=8ms，用户体验会非常好。

流量削峰

我们大家都知道tb、jd上有抢购活动，当抢购时间一到，会有几百万的人同时进入网站进行抢购。每秒并发会有几百万条数据，但数据库的处理速度只有1w/s左右，这将对整个系统是一个非常大的压力。

如果使用了MQ，每秒百万个请求写入MQ，因为系统每秒能处理1W+的请求，系统处理完然后再去MQ里面，再拉取1W的请求处理，这样下来，等到抢购高峰期的时候，系统也不会挂掉，但是近一个小时内，系统处理请求的速度是肯定赶不上用户的并发请求的，所以都会积压在MQ中，甚至可能积压千万条，但是高峰期过后，每秒只会有一千多的并发请求进入MQ，但是系统还是会以每秒1W+的速度处理请求，所以高峰期一过，系统会很快消化掉积压在MQ的请求，在用户那边可能也就是等的时间长一点，但是绝对不会让系统挂掉。

MQ的优缺点

优点：解耦、异步、削峰

缺点：

• 系统复杂程度变高，
• 一致性问题：A系统处理完再传递给MQ就直接返回成功了，用户以为你这个请求成功了，但是，如果在BCD的系统里，BC两个系统写库成功，D系统写库失败了怎么办，这样就导致数据不一致了。