1.消息队列的优点
1）解耦
场景：当A系统需要发送数据到BCD三个系统时。
如果使用接口调用，A系统是和BCD系统耦合在一起的，需要考虑BCD系统挂了怎么办？BCD系统消费失败怎么办？如果E系统也需要这个数据？如果B系统现在不需要这个数据？
如果使用MQ，A系统产生的数据，只要保证消息成功发送到MQ中。各个系统需要数据，自己到MQ中消费。如果新系统需要数据，直接从MQ里消费，如果老系统不需要数据了，直接取消对MQ的消费。
通过MQ，A系统和其他系统彻底解耦了。
2）异步
场景：A系统接到请求，需要在本系统写库，还需要在BCD三个系统写库。
自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。如果同步调用，最终请求总延时是 3 + 300 + 450 + 200 = 953ms。
如果使用MQ，A系统发送三个消息到三个MQ，假设耗时5ms，则A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms。
3）消峰
场景：每天 0:00 到 12:00，A 系统风平浪静，每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ，每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的，大量的请求涌入 MySQL，每秒钟对 MySQL 执行约 5k 条 SQL。
一般的 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死了，导致系统崩溃，用户也就没法再使用系统了。
如果使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。
2.消息队列的缺点
1）系统可用性降低
外部依赖的系统多了，增加了消息队列系统。
2）系统复杂度提高
你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？
3）一致性问题
数据可能不一致。