Options: Kafka,ActiveMQ,RabbitMQ, WebSphere MQ*(IBM),RocketMQ(阿里系) ...
说到消息中间件,估计大伙多多少少都能讲出来一些,ActiveMQ、RabbitMQ、RocketMQ、Kafka 等等各种以及 JMS、AMQP 等各种协议,然而这些消息中间件各自都有什么特点,我们在开发中又该选择哪种呢?今天松哥就来和小伙伴们梳理一下。
AMQP协议介绍 AMQP,即Advanced Message Queuing Protocol,高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。 AMQP的主要特征是面向消息、
分布式微服务系统下,凡是可以“排队”去做的事情,都可以使用消息队列。网上买东西同样也需要“排队付款”,但是有人说,我点确认付款后马上就显示成功了,没感觉到排队呀?其实在后台系统中是排了,只不过排队的时间对于人来说有点短,可能1-2秒就结束了,但是对于计算机来说,这1-2秒的时间很长了。
RabbitMQ现在用的也比较多,但是没有过去那么多啦。现在很多的流行或者常用技术或者思路都是从过去的思路中演变而来的。了解一些过去的技术,对有些人来说可能会产生众里寻他千百度的顿悟,加深对技术的理解,更好的应用于工作中去。
作者 | 厉启鹏 本文以互联网的发展为主线,用叙事的方式向读者再现了消息系统从诞生至今的发展历史。从 1983 年开始,消息系统经历了不同历史时期的历练与打磨,它们的使用方式、功能特性、产品形态、应用场景都发生了非常大的变化。作者选取了五款不同时代的代表性作品,描述了这些产品诞生的历史背景,立足解决的核心问题,并尝试分析它们取得成功的关键因素。最后作者给出了在 Serverless 时代的三个断言,指出了当前消息系统在解决 Serverless 场景存在的核心痛点,展望了未来消息产品应该具备的关键能力,
是不是平常听到说消息队列啊,JMS啊,MQ啊 、kafka啊巴啦啦的一堆术语,听不懂?关系混乱?今天就让我们来一起来看看他们都是什么吧。
Apache RocketMQ 是阿里开源的一款高性能、高吞吐量的分布式消息中间件。
导语 本文梳理笔者 MQ 知识,从消息中间件的基础知识讲起,在有了基础知识后,对市面上各主流的消息中间件进行详细的解析,包括 RabbitMQ、RocketMQ、Kafka、Pulsar,最后再横向对比这几款主流的消息中间件。 消息中间件历史 介绍 MQ 的文章网上千千万,最好的学习途径还是官方文档,文中介绍的这几款 MQ 都在努力推广自己,所以文档在权威性、全面性、专业性、时效性都是无人能及其左右,现在的官网文档甚至自己做竞品比对,比如 RocketMQ 就自己放了比对表格在首页。所以要学好哪一款MQ,
是不是平常听到说消息队列啊,JMS啊,MQ啊 、kafka等一堆术语,听不懂?关系混乱?今天就让我们来一起来看看他们都是什么吧。
1. Brief 一直对Observer Pattern和Pub/Sub Pattern有所混淆,下面打算通过这两篇Blog来梳理这两种模式。若有纰漏请大家指正。 2. Role Publisher:消息发布者,组装原始消息实体并触发消息传递的主体。 Subscriber:消息订阅者,接收消息实体并作出响应的主体。 Message Broker or Event Bus:消息发布者 与
MQ是Message Queue(消息队列)的首字母缩写,基于“先进先出”的数据结构,是一种提供消息队列服务的中间件,也称为消息中间件,是一套提供了消息生产、存储、消费全过程API的软件系统。消息即数据。一般消息的体量不会很大。一般用来解决应用解耦,异步消息,流量削峰等问题,实现高性能,高可用,可伸缩和最终一致性架构。
昨晚收到了应用报警,发现线上某个业务消费消息延迟了 54s 多(从消息发送到MQ 到被消费的间隔):
一、消息中间件相关知识 1、概述 消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能,成为异步RPC的主要手段之一。当今市面上有很多主流的消息中间件,如老牌的ActiveMQ、RabbitMQ,炙手可热的Kafka,阿里巴巴自主开发RocketMQ等。 2、消息中间件的组成 2.1 Broker 消息服务器,作为server提供消息核心服务 2.2 Producer 消息生产者,业务的发起方,负责生产消息传输给broker, 2.3 Consumer 消息消费者,业务的处理方,负责从broker获取消息并进行业务逻辑处理 2.4 Topic 主题,发布订阅模式下的消息统一汇集地,不同生产者向topic发送消息,由MQ服务器分发到不同的订阅者,实现消息的 广播 2.5 Queue 队列,PTP模式下,特定生产者向特定queue发送消息,消费者订阅特定的queue完成指定消息的接收 2.6 Message 消息体,根据不同通信协议定义的固定格式进行编码的数据包,来封装业务数据,实现消息的传输 3 消息中间件模式分类 3.1 点对点 PTP点对点:使用queue作为通信载体
既然应用并没有什么问题,我们来看看 RocketMQ 是否有什么问题。一般的 RocketMQ Broker 的日志我们关心:
中间件:中间件是一种介于操作系统和应用软件之间的一种软件,它使用系统软件所提供的基础服务(功能),衔接网络上应用系统的各个部分或不同的应用,能够达到资源共享、功能共享的目的。 若是以新一代的中间件系列产品来组合应用,同时配合以可复用的商务对象构件,则应用开发费用可节省至80%。
上一期,我们讲解了ActiveMQ的原理和概念,以及用它来实现MQ的一些优势,今天我们来写一个入门级的示例。 首先,在写示例之前,我们先了解下ActiveMQ关键词。 ---- ActiveMQ关键词 ---- ActiveMQConnectionFactory 实现了jms的ConnectionFactory,Connection的工厂类 Connection JMS连接,和Java连接池的Connection差不多 Producer和Consumer用来和Broker通讯的 Session 会话
可能你在没学消息中间件之前都已经听过很多概念了,JMS,AMQP,ActiveMQ,RabbitMQ,Kafka,RocketMQ,一个消息中间件怎么能搞出怎么多概念?乱不乱啊, 别烦,本文从历史的角度帮你理清这些MQ和协议之间的关系。
MQ(message queue)本质是个队列,遵循FIFO先入先出原则,用于上下游传递信息。
Broker:接收和分发消息的应用,RabbitMQ Server 就是 Message Broker
本文的宗旨在于通过简单干净实践的方式教会读者,使用 Docker 配置 RocketMQ 并在基于 DDD 分层结构的 SpringBoot 工程中使用 RocketMQ 技术。因为大部分 MQ 的发送都是基于特定业务场景的,所以本章节也是基于 《MyBatis 使用教程和插件开发》 章节的扩展。
通过之前文章的学习,我们已经对RocketMQ的基本架构有了初步的了解,那今天王子就和大家一起来点实际的,用代码和大家一起看看RocketMQ的几种发送模式和消费模式。好了,让我们开始吧。
点对点模型是基于队列的,生产者发消息到队列,消费者从队列接收消息,队列的存在使得消息的异步传输成为可能。
有一个大的系统由A系统和B系统组成,A系统先将数据发送给MQ,然后MQ将数据发送给B系统,实现A系统和B系统之间的数据传输。A系统生产数据,称为生产者。B系统消费数据,称为消费者。MQ为存储数据的消息中间件。
RocketMQ 是阿里巴巴在2012年开源的分布式消息中间件,目前已经捐赠给 Apache 软件基金会,并于2017年9月25日成为 Apache 的顶级项目。作为经历过多次阿里巴巴双十一这种“超级工程”的洗礼并有稳定出色表现的国产中间件,以其高性能、低延时和高可靠等特性近年来已经也被越来越多的国内企业使用。其主要特点有:
image.png 一般采用“回调网关+MQ”方案来解耦: a、调用方直接跨公网调用微信接口 b、微信返回调用成功,此时并不代表返回成功 c、微信执行完成后,回调统一网关 d、网关将返回结果通知MQ e、请求方收到结果通知
前面一篇文章分析了broker的启动过程,浏览了broker的基本功能。接下来的几篇文章,准备按照十分钟入门RocketMQ一文中提到的一系列特性,依次进行学习。这篇文章准备分析RocketMQ作为MQ的最基本的功能:消息的发布(publish)和订阅(subscribe)。首先,我参考Spring Boot系列文章(六):SpringBoot RocketMQ 整合使用和监控这篇文章完成了一个简单的例子。
操作系统版本:SUSE Linux Enterprise Server 10 SP4 32bit
分区有序:根据key进行路由选择,相同的key会路由到相同MessageQueue
本文讲述了在服务化架构下,如何保证多个子系统间业务数据的一致性。文章首先介绍了事务的概念和特性,然后通过举例说明了分布式事务的不足和本地事务的缺陷。接着,文章提到了一种基于消息系统的方案,该方案由本地消息表和MQ组成,能够屏蔽业务操作细节,实现事务一致性。最后,文章介绍了RocketMQ的事务消息方案,该方案能够保证业务操作和发送消息满足一致性。
rocketMQ:RocketMQ 是什么?Github 上关于 RocketMQ 的介绍:RcoketMQ 是一款低延迟、高可靠、可伸缩、易于使用的消息中间件。具有以下特性:
随着服务规模的扩大,单机服务无法满足性能和容量的要求,此时需要将服务拆分为更小粒度的服务或者部署多个服务实例构成集群来提供服务。在分布式场景下,RPC是最常用的联机调用的方式。
本文梳理笔者的MQ知识,从消息中间件的基础知识讲起,在有了基础知识后,对市面上各主流的消息中间件进行详细的解析,包括 RabbitMQ、RocketMQ、Kafka、Pulsar,最后再横向对比这几款主流的消息中间件。
这一步先拉取rocketmqinc/rocketmq镜像,docker pull rocketmqinc/rocketmq
(1)NameServer是一个几乎无状态的节点,可集群部署,节点之间无任何信息同步
下图展示了生产者DefaultMQProducer 类的构造函数,包装类 DefaultMQProducerImpl 是我们这一小节的核心。
Broker其实就是实现了用代码的形式启动了ActiveMQ将MQ嵌入到java代码中,以便随时用随时启动,在用的时候再去启动这样能节约资源,也保证了可靠性。
DefaultMQProducer是一个默认的消息生产者,可以支持发送普通消息和顺序消息。
分布式消息系统作为实现分布式系统可扩展、可伸缩性的关键组件,需要具有高吞吐量、高可用等特点。而谈到消息系统的设计,就回避不了两个问题:
前传:分布式消息队列 RocketMQ 源码分析 —— Message 拉取与消费(上) 本文主要基于 RocketMQ 4.0.x 正式版 1、概述 2、Consumer 3、PushConsumer 一览 4、PushConsumer 订阅 5、PushConsumer 消息队列分配 6、PushConsumer 消费进度读取 7、PushConsumer 拉取消息 8、PushConsumer 消费消息 9、PushConsumer 发回消费失败消息 10、Consumer 消费进度 11、结尾 --
我们都知道队列,一端入队,一端出队。消息队列也是类似的结构,一端生产者只负责往队列里发送消息数据,另一端消费者只负责从队列里获取数据,获取方式可能是队列推送或者消费者拉取
现在有 2 个服务,Service A 和 Service B,通过 REST 接口通信;Service A 在某个业务场景下调用 Service B 的接口完成一个计算密集型任务,假设接口为 http://service_b/api/v1/domain;该任务运行时间很长,但 Service A 不想一直阻塞在接口调用上。为了满足 Service A 的要求,通常有 2 种方案:
这篇博客聊聊关于RocketMQ相关的东西,主要聊的点有RocketMQ的功能使用、RocketMQ的底层运行原理和部分核心逻辑的源码分析。至于我们为什么要用MQ、使用MQ能够为我们带来哪些好处、MQ在社区有哪些实现、社区的各个MQ的优劣对比等等,我在之前的文章《消息队列杂谈》已经聊过了,如果需要了解的话可以回过头去看看。
Message Queue消息传送系统提供传送服务。消息传送依赖于大量支持组件,这些组件负责处理连接服务、消息的路由和传送、持久性、安全性以及日志记录。消息服务器可以使用一个或多个代理实例。
领取专属 10元无门槛券
手把手带您无忧上云