中间件之消息队列

一、概述

消息队列本质上就是一个中转站，如下图，生产者将消息发送到一个叫消息队列的容器中，然后消费者从容器中去取自己需要的消息。有没有觉得和分布式系统的注册中心有点像啊。

这就是最原始最简单的消息队列——队列模型，允许多个生产者往同一个队列中发送消息，但同一时刻只能有一个消费者获取消息，消费完后消息被删除。

由于队列模型中的消息只能被一个消费者消费，若多个消费之都想要消费同一个消息，则队列模型无法满足需求，因此就在队列模型的基础上衍生出了发布-订阅模型，这也成为现在主流的消息队列模型。

在发布-订阅模型中，存放消息的容器变为了主题，订阅者在接受消息前需要先订阅主题，然后就可以获取订阅主题的所有消息。

发布-订阅模型也遵循消息队列的三要素：生产者、消费者（订阅者）和容器（主题），唯一的不同点在于：一份消息可以被多次消费。

二、应用场景

三个最主要的应用场景：解耦、异步、削峰

1. 解耦

就下面这个订单系统，客户支付成功后，还需要计算优惠、计算积分、发送短信等操作，如果没有消息队列，则需要这些操作都完成才能返回结果。

引入消息队列后，支付系统完成后，发送一个支付成功的消息到队列，然后支付返回结果，其它系统如计算积分系统直接订阅队列中的支付成功消息，然后进行积分的计算就可以了。从而实现解耦，大大缩短系统响应时间。

2. 异步

两个系统A和B，系统B需要使用系统A中步骤一的结果才能执行

若不适用消息队列，则必须等系统A全部执行完毕，系统B才能拿到需要的值然后执行，这样就导致系统B明明只需要系统A步骤一的结果，却要等到系统A全部执行完才能执行，原本不那么相关的东西但是得串行执行。

引入消息队列后，如下所示，系统A的步骤一执行完毕后，就可以将系统B需要的值发送给消息队列，然后继续往下执行，而此时系统B可以从消息队列中拿到需要的值，也能同步开始执行，从而实现异步。

3. 削峰

就拿双十一来说吧，10亿人买东西，去请求数据库，并发量巨大，会导致数据库异常，而有了消息队列后，可以把这些请求存放到队列中，每次取系统的最大安全并发量的消息取操作数据，完成削峰的目的，如下图：

三、消息队列的缺点

1. 系统可用性降低

   因为引入了消息队列，就相当于引入了一个组件，若这个组件挂了，则整个系统也就挂了。因此，系统可用性降低

2. 系统复杂性增加

   如一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。因此，需要考虑的东西更多，系统复杂性增大。

四、常用消息队列比较