消息队列核心使用场景：削峰，解耦，异步
MQ的好处
削峰：
比如抢购秒杀，不在这个点上的时候，可能每秒只有50次请求，但是开始秒杀的时候每秒的请求数可能可以达到上万次，如果这些操作直接落点在数据库上，
拿MYSQL来说，一般MYSQL一秒最多可以处理2000条请求，一秒上万的请求基本直接就把服务器给打死了。
但是如果先将请求在消息队列中堆积起来，消息队列可能每秒进来10000条数据，但是只能处理2000条，那么在高峰时可能在消息队列中会堆积几万条请求，
但是这是可以接受的，一旦秒杀结束，服务器还在以每秒2000条请求的速度慢慢处理。
解耦：
服务器A如果需要将请求委托给BCD，如果不采用消息队列，就要将调用代码写在服务器A中，这样耦合是非常恐怖的，并且如果B服务器在处理时出错了或挂掉了
怎么办呢？再或者说此时又有一台服务器E需要调用A的这些数据呢？A是没办法解决这些问题的。
如果使用消息队列，A只需要将关键的信息放到消息队列中，BCD甚至E自行去队列中消费就行了，A只负责提供信息，不在乎谁使用了数据，也不在乎谁在使用
中出现了问题。
异步：
如果客户端直接请求服务器A，然后服务器需要将部分业务委托给服务器BCD，此时如果A接收请求需要5ms，BCD服务器分别需要300ms，450ms，350ms，
这样全部处理完后需要1秒的时候用户才能得到反馈。这样用户肯定时接受不了的。
但是如果采用消息队列，服务器A可以将信息放在队列中，这个过只需要3ms，BCD再分别去队列中削峰。这样整个过程只需要5ms+3ms，用户得到反馈的时间
大大的缩短了
最后再说说引入了消息队列后的问题：
系统可用性降低：系统依赖的越多，越不稳定，就比如A在分发请求关联BCDE时，是以消息队列为媒介的，如果消息队列本身挂掉了，就完了。
系统复杂度提高：代码在处理数据时肯定时更加的复杂了
数据的一致性：BCD处理信息时，如果D挂掉了，那么BC是否需要回滚刚刚的数据？