消息队列

一. 消息队列

为什么使用消息队列

消息队列是分布式系统中重要组件，使用场景很多，比较核心的有3个：解耦，异步消息，流量削峰。

解耦：

这样一个场景：A系统发送数据到B，C，D三个系统，通过接口调用发送。如果E系统也要这个数据，而C系统现在不需要了，这样A系统负责人就需要做很多操作....

在这个场景中，A系统和其他各种系统严重耦合，A系统产生一条比较关键的数据，很多系统都需要A将这个数据发送过来。A系统要考虑BCDE等系统挂掉怎么办：要不要重发，要不要把消息存起来...

如果使用消息队列，A系统产生一条数据，发送到消息队列中，那个系统需要就自己去消息队列中取。如果新系统需要数据，直接去消息队列中消费即可。如果其它系统不需要这条数据了，就取消堆消息队列的消费即可。这样A系统就不需要考虑要给谁发数据，也就不需要进行维护(考虑需要数据的系统是否调用成功，失败超时等情况)。

总结：通过消息队列，发布和订阅消息这个模型中，A系统就和其它系统彻底解耦了。
异步

场景：A系统接到一个请求，需要在自己本地写库，还需要在B，C，D三个系统写库，自己本地写库需要3ms，其他三个系统分别需要300面ms，400ms，250ms。最终总延时为3 + 300 + 400 + 200 = 953ms，接近1s，给用户的感觉就是慢死了。用户发起一个请求，等待1s，这个会让用户很难接受。

一般互联网类企业，对于用户直接操作，一般要求是每个请求都在200ms以内完成，对用户几乎是无感的。

使用消息队列，那么A系统连续发3条消息到队列中，假如耗时5ms，A系统接受一个请求到返回响应给用户，总时长是3 + 5 = 8ms，对于用户体验就会很爽。
削峰

淘宝系统平时都是风平浪静，每秒并发请求数量假如是100个。但当特殊时间比如双十一，十二等，在几个小时内，每秒并发请求数量突然暴增到10K+条。但是系统每秒只能处理2k请求，如果没秒请求数到达10k+，可能就直接导致系统崩溃了，用户就再也没办法是用系统了。但是高峰期一过，就成了低峰期，可能也就1w的用户同时在淘宝上操作，每秒的并发请求数量可能也就100个，对整个系统是没有任何压力的。使用消息队列后，每秒将10k个请求写入队列中，淘宝系统每秒钟最多处理2k个请求，所以系统每秒会在队列中拉去2k请求，不会超过自己的最大处理请求数，这样即使高峰期，也不会是系统挂掉。这样队列每秒10k请求进来，系统每秒2k拉取，结果就是导致高峰期，会有几十万甚至几百万的请求积压在队列中。短暂的积压是OK的，应为过了高峰期，每秒就会很少请求进入队列，但是系统让是没秒2k的拉取处理。这样高峰期一过，系统就会快速的将积压的请求处理掉。

二. 消息队列的优缺点

优点就是上述的，解耦，异步，削峰。
缺点：

①. 系统可用性降低：系统引入的外部依赖越多，系统越容易挂掉。本来是A系统调用BCD三个系统接口就好了，四个系统好好的不出问题，但是引入消息队列后，万一消息队列挂掉了，整套系统不就挂掉了。如何保证消息队列的高可用？(再研究吧).

②. 系统复杂度增高：加入消息队列后，如何保证消息没有重复消费(如何保证幂等性)？如何处理消息丢失的情况？怎样保证消息传递的顺序性？等等

③. 一致性问题：A系统处理完成了直接返回成功了，人们以为这个请求就成功了；但是问题是：如果其他系统出现写库失败了怎么办，这样数据就不一致了。