关于消息队列:消息队列引论

我的项目中用到了音讯队列，然而本人还只是大略理解，于是打算零碎的学习一下。学货色肯定要留神领会思维，了解了思维就是学一通百，不留神了解思维，很容易就会吞没在技术的陆地中。

MQ 与 JMS

java 是一个喜爱公布规范，让他人实现的语言，这个规范你能够了解为接口，像 JDBC 就是一组接口，由不同的数据库厂商负责实现，这是一个相当胜利的设计。JMS 也是相似于 JDBC 这样的规范，然而并没有做到像 JDBC 这么胜利，所有的音讯服务都按 JMS 来。

已经的我认为 MQ 和 JMS 的关系是这样的:

像是接口和实现类一样，

然而实际上: 只有 ActiveMQ 齐全恪守了 JMS 协定。RocketMQ、RabbitMQ、KafkaMq 并不怎么恪守 JMS。

JMS 是什么?

The Java Message Service (JMS) API is a messaging standard that allows application components based on the Java Platform Enterprise Edition (Java EE) to create, send, receive, and read messages. It enables distributed communication that is loosely coupled, reliable, and asynchronous.

java 音讯服务接口是一个基于 java 平台创立、发送、接管音讯的规范，在分布式系统中经常被用来解耦合，异步发送音讯。

MQ = message queue

message queue 音讯队列，首先是队列，队列是一种数据结构，个别状况是先进先出。

那咱们个别用音讯队列来做什么呢? 或者音讯队列能够用来做什么呢？

能够用来做中间件

那什么是中间件? 查了一些材料，发现并没有严格的定义，目前较为承受的定义是将具体业务和底层逻辑解耦的组件。
咱们权且能够将其了解为中介，咱们想要租房的话，通常不会本人去找房东，通常也比拟难找，也比拟麻烦。如果你真的不想让中介占到一点便宜，跟某块地区的房东曾经建设了策略单干关系，于是你每换一个中央就要本人再找一下房东，你于这个地区就产生了重大的耦合，房东也与你产生了耦合。

通常状况下，房东会将本人的房子委托给中介或者托管在某个平台，租房子的人通过中介或者托管平台来看房子。这个中介和被托管的平台咱们就能够了解为中间件。无效的实现了房东和访客解耦，房东和租房子的人通过中介或托管平台交换。

所以你能够看到 Redis 也能够算进中间件，Redis 也能够做音讯队列。

理论的利用场景中，MQ 被当做中间件时往往用于两个零碎间进行通信，

A 零碎将 B 零碎须要的音讯放入音讯队列中，B 零碎从音讯队列中获取。

有人可能会问了，为什么 B 零碎不间接调用 A 零碎的接口呢？要放一个音讯队列呢？
其实也不是不行，那这样就耦合在一起了，也就是说 A 跟着动，B 也要跟着动，软件行业广泛讨厌改变。
如果是在分布式系统中，咱们就更心愿调用关系清晰一点了，两个零碎在某种意义上像是两个国家，两个国家之间的交换是通过外交部，而两个零碎之间的交换就是通过音讯队列。

削峰填谷

音讯队列的另一个利用场景就是秒杀，秒杀状况下，一段时间内申请会很多，零碎会承受不住这么多申请，申请也能够算做音讯。

就可能让零碎自身解决的申请量，放弃在一个安稳的程度。

异步音讯

事实上这根中间件有些重合，也能够算到解耦合的一部分。
这也是阿里巴巴在介绍 RocketMQ 使长江的第一个场景: 异步解耦。
作为淘宝 / 天猫主站最外围的交易系统，每笔交易订单数据的产生会引起几百个上游业务零碎的关注，包含物流、购物车、积分、阿里妈妈、流计算剖析等等，整体业务零碎宏大而且简单，架构设计稍有不合理，将间接影响主站业务的连续性。
一个订单算作一个音讯，会被多个零碎应用，像极了生产者、消费者模型。作为生产订单的这一方，并不间接和生产订单的这一方产生间接分割。

支流的 MQ 产品

• RocketMQ

阿里巴巴出品，当初交给 apache 开源基金会保护。并不齐全恪守 JMS 协定，反对的协定也比拟多，性能弱小。分布式易宽展。

• ActiveMQ

Apache 出品，反对的协定比拟多: AMQP、STOMP、MQTT、JMS。java 编写，能够将数据间接长久化到数据库中，可靠性比拟低 (发送的音讯可能会失落)

• RabbitMQ

erlang 语言编写，性能强，可靠性比拟高
KafakaMQ: linkedin 开源 MQ，齐全分布式架构，高吞吐量。设计之初是为了解决日志，个别作用于大量数据的数据收集业务。