学习路线指引(点击解锁) | 知识定位 | 人群定位 |
---|---|---|
Python实战微信订餐小程序 | 进阶级 | 本课程是python flask+微信小程序的完美结合,从项目搭建到腾讯云部署上线,打造一个全栈订餐系统。 |
Python量化交易实战 | 入门级 | 手把手带你打造一个易扩展、更安全、效率更高的量化交易系统 |
说到消息队列,相信大家并不陌生。大家在日常的工作中其实都有用过。相信大部分的研发在使用消息队列的过程中也仅仅是停留在用上面,里面的知识点掌握得并不是很系统,有部分强大的功能可能由于本身公司的业务形态或者业务量级的原因根本无法触及到。老猫在工作中就是如此,所使用的MQ都是架构师封装好的,简单调用即可。为了更好地了解其所以然,所以老猫就花时间好好梳理了一下MQ的一系列的知识点,俗话说“好记心不如烂笔头”,所以老猫在学习的过程中就记录了下来。分享出来给有需要的小伙伴,当然也方便后续自己查阅,因此就有了该系列文章。
大家在工作中很多就接触过RabbitMq,其实RabbitMq就是AMQP协议的一种实现。
与其说AMQP是一种协议,其实它更是一种标准。是应用层协议的一个开放标准,为面向消息的中间件设计。AMQP是一个进程间传递异步消息的网络协议。 全称为AMQP(Advanced Message Queuing Protocol)。基于此协议的客户端与消息中间件可传递消息,并不受客户端/中间件不同产品,不同开发语言等条件的限制。AMQP的主要特征是面向消息、队列、路由(包括点对点和发布/订阅)、可靠性、安全。AMQP在消息提供者和客户端的行为进行了强制规定,使得不同卖商之间真正实现了互操作能力。
相信大家的工作日常中除了用RabbitMQ之外很多小伙伴也用过kafka吧,那么kafka和AMQP有什么关系么?
答案是:没关系。
Kafka根本不是消息队列。按官方说法,Kafka是一个流式处理平台(stream processing platform)。Kafka在设计之初是为了支持高吞吐量的日志处理的,只不过它恰好也可以实现消息队列的大部分功能而已。Kafka所用的“黑科技”(例如零拷贝/内存映射,以及对page cache的利用,当然这些后续分享kafka的时候再和小伙伴同步)都是脱离标准消息队列的设计范畴的,所以不能简单地认为Kafka比RabbitMQ等符合AMQP的消息队列更优。例如,RabbitMQ支持死信队列、延迟队列、优先队列、多租户、推模式消费等,Kafka统统不支持。
说到AMQP协议,就不得不聊JMS。 JMS是早期消息中间件进行标准化的一个尝试,它仅仅是在API级进行了规范。 只适用于Java平台的消息中间件规范,支持Java应用程序之间进行消息交换。并且通过提供标准的生产、发送、接收消息的接口简化企业应用的开发。 如果想要详细了解JMS的小伙伴其实百度百科就有很详细的讲解。具体链接:https://baike.baidu.com/item/JMS/2836691?fr=aladdin,
另外如果有小伙伴想要其具体的接口文档,可以在此进行下载:https://download.oracle.com/otndocs/jcp/7195-jms-1.1-fr-spec-oth-JSpec/
JMS主要包括两种模型,(1)点对点模型(2)发布订阅模型
点对点:生产者向队列投递一条消息只有一个监听者才能获取该条消息。
发布订阅:生产者向队列投递一条消息,所有监听该队列的订阅者都可以拿到该消息。
JMS定义了五种不同的消息正文格式,以及调用的消息类型,允许你发送并接收以一些不同形式的数据,提供现有消息格式的一些级别的兼容性。
上述做了一些简单的概括,如果小伙伴觉得有所欠缺,不是太全,那么可以自行查阅相关资料。
对比方向 | JMS | AMQP |
---|---|---|
定义 | Java API | 协议 |
跨语言 | 否 | 是 |
跨平台 | 否 | 是 |
对比模型 | ①Peer-2-Peer(点对点);②Pub/sub(发布订阅) | ①direct exchange;②fanout exchange;③topic change;④headers exchange;⑤system exchange。本质来讲,后四种和JMS的pub/sub模型没有太大差别,仅是在路由机制上做了更详细的划分;(这块后续老猫和大家分享rabbitMq的时候会详细说到) |
消息类型 | 支持多种消息类型 ,我们在上面提到过 | byte[](二进制) |
关于AMQP协议的简单介绍大概就到这里。有小伙伴觉得不够详细的地方当然也可以自发去找找更多的资料。后面老猫会重点整理RabbitMq以及Kafka的知识点和大家分享。期待你的持续关注。