本篇内容主要讲解“怎么从0到1设计一个MQ消息队列”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习”怎么从0到1设计一个MQ消息队列”吧!
<强>消息队列整体设计思路强>
主要是设计一个整体的消息被消费的数据流。
这里会涉及到:消息生产生产商代理(消息服务端),消息消费者消费者。
<中心>![怎么从0到1设计一个MQ消息队列](/zixun/d/file/jishu/2021-11-06/f68d8945371de931cdf73b0e4bb8c6de.jpg )
1.生产者(消息生产者):发送消息到经纪人。
2.代理(服务端):代理这个概念主要来自于Apache的ActiveMQ,特指消息队列的服务端。
主要功能就是:把消息从发送端传送到接收端,这里会涉及到消息的存储,消息通讯机制等。
3.消费者(消息消费者):从消息队列接收消息,消费者回复消费确认。
<强>代理(消息队列服务端)设计重点强>
1)消息的转储:在更合适的时间点投递,或者通过一系列手段辅助消息最终能送达消费机。
2)规范一种范式和通用的模式,以满足解耦,最终一致性,错峰等需求。
3)其实简单理解就是一个消息转发器,把一次RPC做成两次RPC,发送者把消息投递到代理,代理再将消息转发一手到接收端。
总结起来就是两次RPC加一次转储,如果要做消费确认,则是三次RPC。
<强>为了实现上述消息队列的基础功能:强>
1)消息的传输
2)存储
3)消费
<强>就需要涉及到如下三个方面的设计:强>
1)通信协议
2)存储选择
3)消费关系维护
<强>通讯协议强>
消息信息:,既是信息的载体,消息发送者需要知道如何构造消息,消息接收者需要知道如何解析消息,它们需要按照一种统一的格式描述消息,这种统一的格式称之为消息协议。
传统的通信协议标准有XMPP和AMQP协议等,现在更多的消息队列从性能的角度出发使用自己设计实现的通信协议。
<强> 1。JMS 强>
JMS (Java MessageService)实际上是指JMS, API.JMS是由太阳公司早期提出的消息标准,旨在为Java应用提供统一的消息操作,包括创建消息,发送消息,接收消息等。
JMS通常包含如下一些角色:
<中心>![怎么从0到1设计一个MQ消息队列](/zixun/d/file/jishu/2021-11-06/f538f80e6c7195268f79d210de8a242e.jpg )
JMS提供了两种消息模型:
1)点对点
2)以及发布-订阅(发布订阅)模型。
当采用点对点模型时,消息将发送到一个队列,该队列的消息只能被一个消费者消费。
<中心>![怎么从0到1设计一个MQ消息队列](/zixun/d/file/jishu/2021-11-06/8ca2218929a3ff347bc204e9b7fbf722.jpg )
而采用发布订阅模型时,消息可以被多个消费者消费。
在发布订阅模型中,生产者和消费者完全独立,不需要感知对方的存在。
<强> 2。AMQP
AMQP是 Advanced Message Queuing Protocol,即高级消息队列协议。
AMQP不是一个具体的消息队列实现,而 是一个标准化的消息中间件协议。
目标是让不同语言,不同系统的应用互相通信,并提供一个简单统一的模型和编程接口。 目前主流的ActiveMQ和RabbitMQ都支持AMQP协议。
AMQP是一种协议,更准确的说是一种binary wire-level protocol(链接协议)。这是其和JMS的本质差别,AMQP不从API层进行限定,而是直接定义网络交换的数据格式。
JMS和AMQP比较
JMS: 只允许基于JAVA实现的消息平台的之间进行通信
AMQP: AMQP允许多种技术同时进行协议通信
3.Kafka的通信协议
Kafka的Producer、Broker和Consumer之间采用的是一套自行设计的基于TCP层的协议。Kafka的这套协议完全是为了Kafka自身的业务需求而定制的。
存储选型
对于分布式系统,存储的选择有以下几种
1.内存
2.本地文件系统
3.分布式文件系统
4.nosql
5.DB
从速度上内存显然是最快的,对于允许消息丢失,消息堆积能力要求不高的场景(例如日志),内存会是比较好的选择。
DB则是最简单的实现可靠存储的方案,很适合用在可靠性要求很高,最终一致性的场景(例如交易消息),对于不需要100%保证数据完整性的场景,要求性能和消息堆积的场景,hbase也是一个很好的选择。
理论上,从速度来看,文件系统>分布式KV(持久化)>分布式文件系统>数据库,而可靠性却截然相反。