消息中间件

消息中间件

特点
提供数据传输的可靠性和高效性，主要解决分布式的系统数据传输需求
优点
在于能够在客户和服务器之间提供同步和异步的连接
并且在任何时刻都可以将消息进行传送或者存储转发

消息队列（Message Quequing）是在消息传输过程中保存消息的容器。
消息中间件即为消息队列的承载形式消息队列。

比较核心的有 3 个作用：异步、解耦、削峰填谷

消息队列-异步

通过实际案例说明：假设 A 系统接收一个请求，需要在自己本地写库执行 SQL，然后需要调用 BCD 三个系统的接口。假设自己本地写库要 3ms，调用 BCD 三个系统分别要 300ms、450ms、200ms。那么最终请求总延时是 3+300+450+200=953ms，接近 1s，可能用户会感觉太慢了

但是一旦使用了 MQ 之后，系统 A 只需要发送消息到 MQ 中的消息队列，然后就返回给用户了。假设发送消息到 MQ 中耗时 20ms，那么用户感知到这个接口的耗时仅仅是 20+3=23ms，用户几乎无感知。此时整个系统结构大概是这样的：

消息队列-解耦

有这么一个简单的场景，系统A负责生成userID，并调用系统B、C。如果系统BC频繁变化是否需要userID参数，则系统A的代码就得不断变化，如果哪天又来了系统DEF……也需要这个参数，则系统A又要加入很多业务逻辑，这样子各他系统之间就容易产生相互影响，另外大量的系统与A发生交互也容易产生问题。

加了消息队列后，A只负责产生userID，至于谁要用这个参数，怎么用？系统A不管。对这个数据感兴趣的系统自己去取用即可，各个系统之间就实现了解耦。而且解耦后，整个服务业变成了一个异步的方式，系统A产生数据后，不用依次调用BCD来累计耗时，各系统可以同时来取用消息队列的数据进行处理，加大吞吐。

消息队列-削峰填谷

削峰作用的功能——即通过异步处理，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务。

举个例子，比如我们的订单系统，在下单的时候就会往数据库写数据。但是数据库只能支撑每秒 1000 左右的并发写入，并发量再高就容易宕机。低峰期的时候并发也就 100 多个，但是在高峰期时候，并发量会突然激增到 5000 以上，这个时候数据库肯定死了。

但是使用了 MQ 之后，情况就变了! 消息被 MQ 保存起来了，然后系统就可以按照自己的消费能力来消费，比如每秒 1000 个数据，这样慢慢写入数据库，这样就不会打死数据库了。

消息队列-缺点

1、系统可用性降低
大家想象一下，上面的说解耦的场景，本来 A 系统的哥们要把系统关键数据发送给 BC 系统的，现在突然加入了一个 MQ 了，现在 BC 系统接收数据要通过 MQ 来接收。但是大家有没有考虑过一个问题，万一 MQ 挂了怎么办?这就引出一个问题，加入了 MQ 之后，系统的可用性是不是就降低了?因为多了一个风险因素：MQ 可能会挂掉。只要 MQ 挂了，数据没了，系统运行就不对了。

2、系统复杂度提高
本来我的系统通过接口调用一下就能完事的，但是加入一个 MQ 之后，需要考虑消息重复消费、消息丢失、甚至消息顺序性的问题。为了解决这些问题，又需要引入很多复杂的机制，这样一来是不是系统的复杂度提高了。

3、一致性问题
A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了

消息队列分类

消息队列的分类：
push(推消息模型)
消息生产者将消息发送给消息中间件，消息中间件又将消息推送给消费者。
pull（拉消息模型）
消费者请求 消息中间件接收消息，消费者从消息中间件拉取消息。

举个例子：
消息=食物；服务端Broker=老爸；消费端 = 儿子

如果采用Push模型：
优点：老爸一拿到食物就给儿子吃【食物送达及时】
缺点：儿子已经吃跑了，老爸还强塞儿子吃，可能导致儿子被撑死【儿子不堪重负，撑死了】

如果采用Pull模型
优点：儿子饿了，主动找老爸要食物，不饿的时候不要。【儿子根据饥饿程度获取食物】
缺点：儿子饿了，发消息给老爸给我点食物，等老爸收到消息已经过了十分钟了，儿子等不及了饿死了。【食物没有及时送给儿子】

消息队列的传递模型（一）

点对点（P2P）即一个生产者和一个消费者一一对应
 发送者和接收者中有一个消息队列(messages quene),发送者发送消息则把消息加入到队列中，接收者接收消息则把消息从队列中取出；如果接收者没有接收，则这条消息永远保存在队列中(除非已过期)。

点对点模型的特点：
使用queue作为通信载体
消息被消费以后，queue中不再存储，所以消息消费者不可能消费到已经被消费的消息。
每条消息只能有一个接收者
发送者和接受者没有时间依赖
接收者在成功接收消息之后确认消息接受和处理成功

消息队列的传递模型（二）

•发布-订阅（Pub/Sub）发送者把消息挂在一个主题下，接收者先订阅这个主题，当这个主题有新消息发布时，接收者就可以接收这个主题下的消息了，这个消息一直保持到所有订阅这个消息的人（在线的）都接收了才删除。

发布-订阅模型的特点：
使用topic作为通信载体 （topic：指消费的主题名）
每个次消息可以有多个消费者
客户只有订阅后才能接收消息（只有建立订阅关系才可以接收消息 ）