关于java:消息队列的流派

40次阅读

共计 1228 个字符,预计需要花费 4 分钟才能阅读完成。

大家好,我是尚影嫣🌷,一名 Java 后端程序媛。如果您喜爱我的文章,欢送点赞➕关注❤️,让咱们一起成为更好的咱们~

音讯队列的流派

一、什么是 MQ

Message Queue(MQ)是一种音讯队列中间件。MQ 真正的目标是为了通信,屏蔽底层简单的通信协定,定义了一套更简略的应用层的通信协定。分布式系统中模块之间的通信无非是 HTTP 或 TCP,这两种协定都是原始的协定,MQ 在这些协定之上构建了一个简略的“协定”—— 生产者 / 消费者模型。它定义了两个对象——生产者和消费者,生产者是发送数据方,消费者是接收数据方,提供 SDK 让咱们定义本人的生产者和消费者实现音讯通信,忽视底层通信协定。

二、有 Broker 的 MQ

这类 MQ 通常有一台服务器作为 Broker,所有的音讯都通过它进行直达。生产者只须要将音讯发送给它就实现工作了,Broker 再将音讯被动推送给消费者(或由消费者被动轮询)。

重 Topic

kafka、JMS(ActiveMQ)属于此流派,生产者会发送 key 和数据到 Broker,由 Broker 比照 key 后决定发给哪个消费者。这种模式是咱们最常见的模式,此模式中一个 topic 往往是一个较大的概念,甚至一个零碎中可能只有一个 topic,某种意义上讲 topic 就是 queue。

如上图所示,Broker 定义了三个队列,key1,key2,key3,生产者发送数据的时候会发送 key1 和 data,Broker 在推送数据的时候则推送 data(也可能带上 key)。

尽管架构一样,但 kafka 的性能要比 JMS 的性能高很多倍,所以重 Topic 类型的 MQ 优选 kafka。܉

轻 Topic

轻 Topic 的代表是 RabbitMQ(AMQP)。生产者发送 key 和数据,消费者定义订阅的队列,Broker 收到数据后,通过肯定逻辑计算出 key 对应的队列,并将数据交给队列。此模式解耦了 key 和 queue,在这种架构中 queue 是轻量级的,消费者只关怀本人的 queue,生产者不用关怀数据最终给谁,只须要指定 key 就行,两头的那层映射在 AMQP 中叫 exchange 交换机。

AMQP 中有四种 exchange:

  1. Direct exchange:key 等于 queue;
  2. Fanout exchange:忽视 key,会给所有 queue 各发一份;
  3. Topic exchange:key 能够用“宽字符”含糊匹配 queue;
  4. Headers exchange:忽视 key,通过查看音讯的头部元数据来决定发给哪个 queue。

三、无 Broker 的 MQ

无 Broker 的 MQ 的代表是 ZeroMQ。MQ 是更高级的 Socket,它是用来解决通信问题的,ZeroMQ 被设计成了一个库,而不是一个中间件,这种实现也能够达到无 Broker 的目标。

节点之间通信的音讯发送到彼此的队列中,每个节点都既是生产者又是消费者。ZeroMQ 做的事件就是封装出一套相似于 Socket 的 API,能够实现发送和读取数据。

本文参加了思否技术征文,欢送正在浏览的你也退出。

正文完
 0