为什么要使用消息队列，六个字总结：解耦、异步、消峰。
1）解耦
传统模式下系统间的耦合性太强。怎么说呢，举个例子：系统 A 通过接口调用发送数据到 B、C、D 三个系统，如果将来 E 系统接入或者 B 系统不需要接入了，那么系统 A 还需要修改代码，非常麻烦。
如果系统 A 产生了一条比较关键的数据，那么它就要时时刻刻考虑 B、C、D、E 四个系统如果挂了该咋办？这条数据它们是否都收到了？显然，系统 A 跟其它系统严重耦合。
而如果我们将数据（消息）写入消息队列，需要消息的系统直接自己从消息队列中消费。这样下来，系统 A 就不需要去考虑要给谁发送数据，不需要去维护这个代码，也不需要考虑其他系统是否调用成功、失败超时等情况，反正我只负责生产，别的我不管。
2）异步
先来看传统同步的情况，举个例子：系统 A 接收一个用户请求，需要进行写库操作，还需要同样的在 B、C、D 三个系统中进行写库操作。如果 A 自己本地写库只要 1ms，而 B、C、D 三个系统写库分别要 100ms、200ms、300ms。最终请求总延时是 1 + 100 + 200 + 300 = 601ms，用户体验大打折扣。
如果使用消息队列，那么系统 A 就只需要发送 3 条消息到消息队列中就行了，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 1 + 5 = 6ms，对于用户而言，体验好感度直接拉满。
3）消峰
如果没有使用缓存或者消息队列，那么系统就是直接基于数据库 MySQL 的，如果有那么一个高峰期，产生了大量的请求涌入 MySQL，毫无疑问，系统将会直接崩溃。
那如果我们使用消息队列，假设 MySQL 每秒钟最多处理 1k 条数据，而高峰期瞬间涌入了 5k 条数据，不过，这 5k 条数据涌入了消息队列。这样，我们的系统就可以从消息队列中根据数据库的能力慢慢的来拉取请求，不要超过自己每秒能处理的最大请求数量就行。
也就是说消息队列每秒钟 5k 个请求进来，1k 个请求出去，假设高峰期 1 个小时，那么这段时间就可能有几十万甚至几百万的请求积压在消息队列中。不过这个短暂的高峰期积压是完全可以的，因为高峰期过了之后，每秒钟就没有那么多的请求进入消息队列了，但是数据库依然会按照每秒 1k 个请求的速度处理。所以只要高峰期一过，系统就会快速的将积压的消息给处理掉。
