消息队列MQ与微消息队列MQTT

文章目录

参考文章
什么是消息队列，什么是RPC
为什么要使用MQ消息队列
- 1. 解耦（可用性）
- 2. 流量削峰
- 3. 数据分发
消息队列的缺点
多种主流传统消息队列MQ对比
传统消息队列RocketMQ和微消息队列MQTT对比

参考文章

https://www.jianshu.com/p/15081799d66b
非常好的描述消息队列应用场景文章1
非常好的描述消息队列应用场景文章2
https://www.cnblogs.com/mokafamily/p/9061322.html

什么是消息队列，什么是RPC

在分布式服务器和服务器通信时，RPC可以解决问题。
而我们使用消息队列一个主要优势就是，增加消息的堆积能力，也就是类似于Java线程池实现基本原理就是消息中间件。当然这也增加了维护成本。和复杂度。

所以现在一般都不使用RPC

为什么要使用MQ消息队列

1. 解耦（可用性）

不同服务器系统之间使用RPC调用，会使系统之间的耦合性非常高。
当一个系统挂了另一个系统就无法使用。可用性降低。

订单系统把消息发送给MQ服务，然后不同的系统再进行消费。当一个系统挂了也不要紧，等恢复的时候再去MQ中拿消息，这样系统的可用性就大大提高了。也就是耦合性没那么高。一个系统不那么依赖于另一个系统。
而使用MQ我们则可以降低该耦合性。

2. 流量削峰

场景1: 当用户量瞬间陡增，秒杀处理系统可以处理这么多的请求，但是当发送给通知系统这样可能压垮数据库。

举个栗子，秒杀业务：

上游发起下单操作。（比如机票系统，火车票系统，等都是上游，只发起请求操作。）

下游完成秒杀业务逻辑（库存检查，库存冻结，余额检查，余额冻结，订单生成，余额扣减，库存扣减，生成流水，余额解冻，库存解冻）

上游下单业务简单，每秒发起了10000个请求，下游秒杀业务复杂，每秒只能处理2000个请求，很有可能上游不限速的下单，导致下游系统被压垮，引发雪崩。

解决：我们使用MQ在中间，这样A系统就每次从MQ拉取我能承受的2K个请求。虽然可能会有一定延迟，但比系统挂了强。

场景2: 也就是我们的需求场景，用户服务器系统，发送大量请求调用我们医疗服务器系统接口。我们系统可能无法承受如此大请求量。那么我们在系统和系统之间加一个MQ服务。进行流量削峰。在这里也考虑到经济目的，因为我们不可能光为了峰值请求而更换硬件和软件，毕竟流量峰值只是短暂的。

3. 数据分发

比如A系统要分发消息给多个系统，那么如果说他每次都发送给B系统C系统D系统，当多个系统更改需求的时候都需要通知A系统，这样对A系统来说很麻烦。使用MQ直接把消息发送给MQ。谁需要消息谁就去MQ拿就非常方便。

消息队列的缺点

添加MQ，如果MQ服务挂了，导致消息发送和接收就无法使用了。
复杂度提高。

多种主流传统消息队列MQ对比

现在使用比较多的是RabbitMQ和Rocket MQ
RabbitMQ是国外的RocketMQ是阿里的。
RocketMQ的支持比较多，可扩展和可用性强。
RabbitMQ是erlang编写的，性能非常好，时效性非常强，但是可扩展性不是很强。

传统消息队列RocketMQ和微消息队列MQTT对比

传统的消息中间件，例如消息队列 RocketMQ、消息队列 RabbitMQ kafka 等都是面向微服务大数据等领域，负责消息的存储和转发，消息的生产者和消费者都是服务端应用。

而移动互联网和 IoT 领域则有所不同，这类场景更侧重于多语言多平台的海量设备接入，消息的生产和消费过程的业务属性很突出，传统的消息中间件并不适合这些领域。

微消息队列 MQTT 在设计上是一个面向移动互联网和 IoT 领域的无状态网关，只关心海量移动端设备的接入、管理和消息传输

http://www.360doc.com/content/19/0514/20/835902_835720104.shtml

基于上图我们可以大概了解，MQTT是架在服务端和客户端之间他可以分发给多个客户端。而RocketMQ是架在服务器与服务器之间。