消息队列
在分布式系统中，经常使用到的一个中间件就是消息队列，所以为什么要使用消息队列，消息队列使用有哪些优缺点？
1.为什么要使用消息队列？
事实上，回答这个问题也就是在考虑消息队列的使用场景，使用消息队列能解决些什么问题：
1.1.解耦
有这么一个场景，在微服务系统中，当A系统产生新数据后需要将数据发送给BCD系统。如果此时E系统也需要，那么A系统需要适配；如果B系统不再需要了，那么A系统也必须要适配；如果有些系统挂了，A系统需不需要重发等。所以A系统与下游系统耦合性很高。如果在它们之间引入MQ(消息队列)，会带来哪些优化。
引入MQ之后，A系统产生新数据之后，直接发送到MQ中，哪些系统需要数据，自己去MQ中消费，如果不需要了，可以取消对MQ的消费操作，这样，A系统不需要再去考虑给谁发送数据问题，依赖MQ的特性，也不需要关注下游服务是否消费成功，重发数据等问题。
总结：通过中间层引入MQ，发布订阅模式，将A系统与下游服务进行业务解耦。
1.2.异步
再看另一个场景，
下图（左），当浏览器发送一个请求到A系统时，这个请求业务的完成需要依赖于BCD系统，比如A系统为订单模块，订单生成之后需要完成B系统的积分等流程，比如A系统业务完成需要3ms，BCD业务完成个需要300ms，所以整个流程需要3+450+500+450=1403ms，这对于一般互联网来说，时长有点不太友好，基本要求在一个请求完成在200ms内
下图（右），引入MQ之后，A系统不在需要等待BCD的同步操作，而是将预期操作同步下发到三个队列中，然后直接返回给浏览器成功，加入这过程耗时5ms，那么总时长为3+5=8ms，非常快，网站做的非常nice！
总结：通过引入MQ实现预期的异步操作，但是会面临最终一致性问题
1.3.削峰
下图（左），假如A系统每天到 12:00 ~ 13:00 ，每秒并发请求数量突然会暴增到 5k+ 条。系统基于 MySQL 做数据处理，每秒并发大概2k，大量的请求涌入 MySQL，可能就直接把 MySQL 给打死了，导致系统崩溃，但是高峰期一过，其他时间可能也就 1w 的用户同时在网站上操作，每秒中的请求数量可能也就 50 个请求，对整个系统几乎没有任何的压力。
下图（右），引入MQ之后，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，不要超过自己每秒能处理的最大请求数量即可，A 系统从 MQ 中慢慢拉取请求，这样哪怕是高峰期的时候，A 系统也绝对不会挂掉。但是MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，会导致在高峰期（1 个小时），可能有几十万甚至几百万的请求积压在 MQ 中。这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压的消息给解决掉。
总结：通过引入MQ存储短时间大量的涌入的数据，给后端系统带来缓冲时间，但是会导致请求积压。
2.优缺点
2.1.优点
上面基本描述了MQ的优点，在一定的场景下实现解耦、异步、削峰等问题。
2.2.缺点
-
系统可用性降低
系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，ABCD 四个系统还好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整？MQ 一挂，整套系统崩溃，你不就完了？如何保证消息队列的高可用？
-
系统复杂度提高
不管是开发还是运维，加入MQ之后，系统的复杂度变高了，维护成本变高，而且会面临怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？等
-
一致性问题
异步中场景，A系统下发到MQ之后就直接返回浏览器成功，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，就会造成不一致性问题。
