关于消息中间件:消息队列MQJMSKafka你都了解吗

是不是平时听到说音讯队列啊，JMS 啊，MQ 啊、kafka 啊巴啦啦的一堆术语，听不懂？关系凌乱？明天就让咱们来一起来看看他们都是什么吧。

音讯队列介绍

首先举个收快递的栗子，传统的收快递，快递小哥把咱们的快递送到咱们的手里。他须要什么条件嗯？

• 快递小哥有工夫送，
• 咱们有工夫取，
• 快递小哥和咱们约定一个工夫地点。

然而嗯。快递小哥有那么多的快递须要送，可能送我快递的时候，我不在家，可能我在家的时候，快递小哥送其余的中央的快递。所以嗯，这个时候，要么就是坐在家里等快递，要么就只能从新约个工夫点在送。那怎么办去防止这个状况嗯？

于是嗯快递柜呈现了。快递小哥不必关怀我什么时候在家，因为快递小哥有工夫了，就把快递放快递柜，而我有工夫了，我就去快递柜取我的快递。

那么快递柜所起到的作用就是咱们明天要收的音讯队列。咱们能够把音讯队列比作是一个寄存快递的的快递柜，当咱们须要获取咱们快递的时候就能够从快递柜外面拿到属于咱们的快递。

什么是音讯队列

咱们能够把音讯队列比作是一个寄存音讯的容器，当咱们须要应用音讯的时候能够取出音讯供本人应用。咱们看看维基百科上的形容：在计算机科学中，音讯队列（Message queue）是一种过程间通信或同一过程的不同线程间的通信形式，软件的贮列用来解决一系列的输出，通常是来自用户。

是不是很难了解，咱们换个说法来了解

咱们能够把音讯队列比作是一个寄存音讯的容器，当咱们须要应用音讯的时候能够取出音讯供本人应用。

音讯队列（Message queue）有什么用？

音讯队列是分布式系统中重要的组件，应用音讯队列次要是为了通过异步解决进步零碎性能和削峰、升高零碎耦合性。罕用消息中间件 17 个维度全方位比照

通过异步解决进步零碎性能（削峰、缩小响应所需工夫）。

举个例子：咱们在某个网站进行注册账号，咱们须要做如下四件事：

• 填写咱们的注册信息；
• 提交咱们的注册信息；
• 咱们的邮箱收到注册信息；
• 咱们的短信收到注册信息。

如果采纳同步串行，所须要的工夫是：a+b+c+d

如果采纳同步并行，所须要的工夫是：a+b+max(c,d)

如果采纳音讯队列，所须要的工夫是：a+b+ 音讯队列

升高零碎耦合性

举个例子，A 公司做了某个零碎，B 公司感觉 A 公司的某个性能很好，于是 B 公司和 A 公司的零碎进行了集成。这时 C 公司也感觉 A 公司的这个性能很好，于是，C 公司也和 A 公司的零碎进行了集成。当前还有 D 公司…。

介于这种状况，A 公司的零碎和其余公司的耦合度都很高，每集成一个公司的零碎，A 公司都须要批改本人的零碎。如果采纳音讯队列，则变成了如下：

不论当前还有多少公司的应用程序想要用 A 公司的程序，都不须要和 A 公司进行集成，谁须要这个性能，谁就去音讯队列外面获取。

音讯队列的两种模式

• 点对点模式

应用程序由：音讯队列，发送方，接管方组成。

每个音讯都被发送到一个特定的队列，接收者从队列中获取音讯。队列保留着音讯，直到他们被生产或超时。

• 公布订阅模式

用用程序有由：角色主题（Topic）、发布者 (Publisher)、订阅者(Subscriber) 形成。

发布者公布一个音讯，该音讯通过 topic 传递给所有的客户端。该模式下，发布者与订阅者都是匿名的，即发布者与订阅者都不晓得对方是谁。并且能够动静的公布与订阅 Topic。Topic 次要用于保留和传递音讯，且会始终保留音讯直到音讯被传递给客户端。

介绍完了音讯队列，接着咱们介绍 JMS

JMS 介绍

JMS 即 Java 音讯服务（Java Message Service）利用程序接口，是一个 Java 平台中对于面向消息中间件（MOM）的 API，相似于 JDBC。用于在两个应用程序之间，或分布式系统中发送音讯，进行异步通信。它提供创立、发送、接管、读取音讯的服务。由 Sun 公司和它的合作伙伴设计的利用程序接口和相应语法，使得 Java 程序可能和其余音讯组件进行通信。

JMS 是一个音讯服务的规范或者说是标准，容许应用程序组件基于 JavaEE 平台创立、发送、接管和读取音讯。它使分布式通信耦合度更低，音讯服务更加牢靠以及异步性。

• 介绍到这里，应该明确了音讯队列和 JMS 的区别了吧？
• 音讯队列：计算机科学中，A 和 B 进行通信的一种形式。
• JMS：java 平台之间分布式通信的一种规范或者标准。
• 换句话说，JMS 就是 java 对于音讯队列的一种实现形式。

JSM 音讯模型

点对点，公布订阅，音讯队列中曾经说的很分明了，这里就不反复说了。

JMS 生产

• 同步（Synchronous）

订阅者 / 接管方通过调用 receive()来接管音讯。在 receive（）办法中，线程会阻塞直到音讯达到或者到指定工夫后音讯仍未达到。

• 异步（Asynchronous）

音讯订阅者需注册一个音讯监听者，相似于事件监听器，只有音讯达到，JMS 服务提供者会通过调用监听器的 onMessage()递送音讯。

JMS 编程模型

JMS 编程模型十分相似于 JDBC。回顾一下，咱们之前讲到的 MyBatis。

• SqlSessionFactoryBuilder 去结构 SqlSessionFactory 会话工厂；
• SqlSessionFactory 会话工厂给咱们关上 SqlSession 会话；
• SqlSession 帮咱们去连贯数据库，接着咱们就能够执行增删查改。

sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream);
SqlSession openSession = sqlSessionFactory.openSession(true);
ProjectMapper mapper = openSession.getMapper(ProjectMapper.class);
mapper.queryAllTaskByInit("init");

JMS 模型如下

• Connection Factory 给我创立 Connection 连贯;
• Connection 连贯给咱们创立了 Session 会话；
• Session 会话给咱们创立消费者和生产者；
• 生产者生成音讯；
• 消费者生产音讯；

MQ 介绍

上文中，咱们说到了，JMS 他并不是一种真正意义的技术，而是一种接口，一种标准。就想 JDBC 一样，无论是 mybatis、hibernate，还是 springJPA，不论你是那种技术实现，反正你得恪守 JDBC 的标准。

在 Java 中，目前基于 JMS 实现的音讯队列常见技术有 ActiveMQ、RabbitMQ、RocketMQ。值得注意的是，RocketMQ 并没有齐全恪守 JMS 标准，并且 Kafka 不是 JMS 的实现。

AMQP 协定

这里咱们以 RabbitMQ 为例介绍 MQ，首先介绍下 AMQP

AMQP 协定（Advanced Message Queuing Protocol，高级音讯队列协定）是一个过程间传递异步音讯的网络协议。

• AMQP 模型

• AMQP 工作过程
• 发布者（Publisher）公布音讯（Message），经由交换机（Exchange）。
• 交换机依据路由规定将收到的音讯分发给与该交换机绑定的队列、（Queue）。
• 最初 AMQP 代理会将音讯投递给订阅了此队列的消费者，或者消费者依照需要自行获取。

RabbitMQ 是 MQ 产品的典型代表，是一款基于 AMQP 协定可复用的企业音讯零碎。

RabbitMQ 模型

RabbitMQ 由两局部组成，别离是服务端和利用端；

• 服务端包含：队列和交换机。
• 客户端包含：生产者和消费者。

在 rabbitmq server 上能够创立多个虚构的 message broker。每一个 broker 实质上是一个 mini-rabbitmq server，别离治理各自的 exchange，和 bindings。

broker 相当于物理的 server，能够为不同 app 提供边界隔离，使得利用平安的运行在不同的 broker 实例上，相互之间不会烦扰。producer 和 consumer 连贯 rabbit server 须要指定一个 broker。音讯队列探秘 – RabbitMQ 音讯队列介绍

Exchange 有 4 种类型：direct(默认)，fanout, topic, 和 headers

• Direct：间接交换器，工作形式相似于单播，Exchange 会将音讯发送齐全匹配 ROUTING_KEY 的 Queue。
• Fanout：播送是式交换器，不论音讯的 ROUTING_KEY 设置为什么，Exchange 都会将音讯转发给所有绑定的 Queue(所谓绑定就是将一个特定的 Exchange 和一个特定的 Queue 绑定起来。Exchange 和 Queue 的绑定能够是多对多的关系)。
• Topic: 主题交换器，工作形式相似于组播，Exchange 会将音讯转发和 ROUTING_KEY 匹配模式雷同的所有队列，比方，ROUTING_KEY 为 user.stock 的 Message 会转发给绑定匹配模式为 .stock,user.stock， . 和 #.user.stock.# 的队列。（ 表是匹配一个任意词组，# 示意匹配 0 个或多个词组）。
• 至于如何在代码中应用 RabbitMQ，这里咱们先不撸代码，本文目前只介绍实践梳理知识点。

Kafka

上完中咱们提到过，kafka 不是 JMS 的实现，因而在 MQ 章节中，咱们没有提及到它。当初咱们开始学习 kafka 吧。大白话带你意识 Kafka

先来放张 kafka 的原理图，置信你看到这个图片时，心田是奔溃的。我草，啥玩意。接下来咱们就一点一点的消化吧。

kafka 原理图

先介绍上图中的术语。

• Producer：音讯生产者，就是向 kafka broker 发消息的客户端。
• Consumer：音讯消费者，向 kafka broker 取音讯的客户端。
• Topic：kafka 给音讯提供的分类形式。broker 用来存储不同 topic 的音讯数据。一个 Topic 能够认为是一类音讯，每个 topic 将被分成多个 partition(区), 每个 partition 在存储层面是 append log 文件。任何公布到此 partition 的音讯都会被间接追加到 log 文件的尾部，每条音讯在文件中的地位称为 offset（偏移量），offset 为一个 long 型数字，它是惟一标记一条音讯。它惟一的标记一条音讯。kafka 并没有提供其余额定的索引机制来存储 offset，因为在 kafka 中简直不容许对音讯进行“随机读写”。
• broker：中间件的 kafka cluster，存储音讯，是由多个 server 组成的集群。
• Partition：为了实现扩展性，一个十分大的 topic 能够散布到多个 broker（即服务器）上，一个 topic 能够分为多个 partition，每个 partition 是一个有序的队列。partition 中的每条音讯都会被调配一个有序的 id（offset）。kafka 只保障按一个 partition 中的程序将音讯发给 consumer，不保障一个 topic 的整体（多个 partition 间）的程序。
• Offset：kafka 的存储文件都是依照 offset.kafka 来命名，例如你想找位于 2049 的地位，只有找到 2048.kafka 的文件即可。当然 the first offset 就是 00000000000.kafka。

相似于 JMS 的个性，但不是 JMS 标准的实现。kafka 对音讯保留时依据 Topic 进行归类，发送音讯者成为 Producer，音讯接受者成为 Consumer, 此外 kafka 集群有多个 kafka 实例组成，每个实例 (server) 成为 broker。无论是 kafka 集群，还是 producer 和 consumer 都依赖于 zookeeper 来保证系统可用性集群保存信息。

kafka 基于文件存储。通过分区, 能够将日志内容扩散到多个 server 上，来防止文件尺寸达到单机磁盘的下限，每个 partiton 都会被以后 server(kafka 实例)保留；能够将一个 topic 切分多任意多个 partitions，来音讯保留 / 生产的效率. 此外越多的 partitions 意味着能够包容更多的 consumer，无效晋升并发生产的能力。

kafka 和 JMS 不同的是: 即便音讯被生产, 音讯依然不会被立刻删除。日志文件将会依据 broker 中的配置要求，保留肯定的工夫之后删除。

Kafka 高可用机制

• 多个 broker 组成，每个 broker 是一个节点；
• 你创立一个 topic，这个 topic 能够划分为多个 partition，每个 partition 能够存在于不同的 broker 上，每个 partition 就放一部分数据。
• 采纳 replica 正本机制，每个 partition 的数据都会同步到其余机器上，造成多个 replica 正本。
• 所有 replica 会选举一个 leader 进去，那么生产和生产都跟这个 leader 打交道，而后其余 replica 就是 follower。
• 读数据时，从 leader 读取，写数据时，leader 把数据同步到所有 follower 下来。如果某个 broker 宕机了，这个 broker 在其余的 broker 还保留正本，假如这个 broker 下面存在 leader, 那么就从新选一个 leader。

内容有点多，须要联合图片一点一点消化。Kafka 是什么，次要利用在什么场景?

生产者结构图

至此，尽管看的云里雾里，不过置信你们还是能辨别了吧？

整顿一下

音讯队列：指计算机领域中，A 和 B 通信的一种通信形式；

JMS：Java 中对于音讯队列的接口标准；

ActiveMQ/RabbitMQ：JMS 接口标准具体实现的一种技术；

RocketMQ：不齐全是 JMS 接口标准具体实现的一种技术；

Kafka：非 JMS 接口标准具体实现的一种技术；

起源：blog.csdn.net/m0_37892044/article/details/106603925