三个主流消息中间件区别

合集下载

常用MQ的对比冷知识

常用MQ的对比冷知识

Kafka
Kafka是一个高吞吐量的分布式发布订阅消息系统,是一个分布式的、分区的、可靠的分布式日志存储服务。它公国一种独一无二的设计提 供了一个消息系统的功能。 Kafka本身不是一个严格意义上的消息中间件,它本身是用来做日志储存的。所以kafka磁盘数据结构提供消息的持久化,这种结构对于及时数以TB的消息存储也能够保持长时间的稳定性能。Kafka储存算法在 持久化方面做得非常好,即使面对TB级别的消息(日志)数据也能给偶偶保持长时间的稳定。 高吞吐量:即使是非常普通的硬件。Kafka也可以支持每秒数百万的消息。 kafka支持分区(Partition)、消费者分组(Consumer Group)
常用 MQ的对比冷知识 16年阿里将 RocketMQ捐赠给了开源软件基金会 Apache,开源路 走在了前面
各类消息中间件对比
ActiveMQ
ActiveMQ是Apache出品的,最流行,能力强劲的开源消息总线。ActiveMQ是一个完全支持JMS1.1和J2EE1.4规范的JMS Provider实现,尽 管JMS规范出台已经是很久的事情了,但是JMS在当今的J2EE应用中间仍然扮演者特殊的地位。
特性
ActiveMQ支持多种语言和协议编写客户端:Java、C、C++、C#、Perl、Python、PHP 支持应用协议:OpenWire、Stomp REST、WS NotificationXMPP、AMQP ActiveMQ完全支持JMS1.1和J2EE1.4规范(持久化,XA消息,事务) ActiveMQ还支持一些高级特性:虚拟主题、组合目的、镜像队列
RabbitMQ
RabbitMQ是一个开源的AMQP实现,服务端用Erlang语言编写。用于在分布式系统中存储转发消息,在易用性、扩展性、高可用性等方面 表现不俗。

消息中间件TongLINKQ7产品介绍

消息中间件TongLINKQ7产品介绍

TongLINK/Q 节点
TongLINK/Q 节点
TongLINK/Q 节点
TongLINK/Q 节点
TongLINK/Q 节点
发送应用 核心进程 消息 消息 发送应用 队列 配置文件 队列 配置文件
节点
产品特性—高易用性
主流平台支持 Windows 系列 Linux 系列 HP-UINX 系列 AIX 系列 Solaris 系列 主流开发语言支持 C C++ JAVA、JMS DELPHI VB …………
TONGLINK/Q介绍
TongLINK/Q 的定位 为企业级分布式系统提供可靠高效的数据传输服务
TongLINK/Q 在业界的领先地位
国内最优秀的消息中间件
1 2 3
93年发布,国内最成熟 稳定提供端到端数据传 输的中间件
全国超过500家 TongLINK/Q的客户,总 装机量超过30万套
全国高速公路联网收费 项目85%的市场占有率
TongLINK/Q中的概念——类比邮政系统与信件
A地邮政局 TLQ A节点 TLQ连接 队列 消息 = 消息头 + 用户数据 用户数据
B地邮政局 TLQ B节点
TongLINK/Q体系架构
外部系统
开发接口
队列控制单元 队列控制单元
核心进程 队列控制单元 核心进程 消息 核心进程 消息 核心进程 消息 消息 核心进程 队列消息 队列消息 配置文件 核心进程 队列 队列 配置文件 队列 队列 配置文件 瘦客 户代 理进 程 监控 代理 进程
高可用性—集群
队列控制单元 队列控制单元
队列
队列控制单元
队列控制单元
集群 队列
集群主机
本地 队列

消息中间件与rabbitmq(一)

消息中间件与rabbitmq(一)

消息中间件与rabbitmq(⼀)本⽂将从三步讲述消息中间件从⽣产消费者模型到消息中间件⽣产消费者模型的作⽤以及适⽤场景⼿动实现消费⽣产者模型的缺陷消息队列消息中间件消息中间件的定义与常⽤类型消息中间价的操作消息中间件的选型消息中间的优缺点消息队列定义消息队列,⼀般我们会简称它为MQ(Message Queue),直⽩的说就是储存消息与释放消息的先进先出结构。

那么把数据放到消息队列叫做⽣产者,从消息队列⾥边取数据则被叫做消费者。

三⼤属性作为消息队列⼀般具备如下3⼤属性:消息顺序 分区有序的队列通过分布式处理,⽀持更⾼的并发,但由于队列的分布式特性,DMS⽆法保证能够以接收消息的精确顺序进⾏消费。

如果⽤户要求保持顺序,建议在每条消息中放置排序信息,以便在收到消息时对消息重新排序。

全局有序的队列对消息消费遵循先⼊先出规则(FIFO),适⽤于对消费顺序要求较⾼的场景。

⾄少⼀次传递 在极少数情况下,当⽤户接收或删除消息时,存储消息副本的服务器之⼀可能不可⽤。

如果出现这种情况,则该不可⽤服务器上的消息副本将不会被删除,并且在接收消息时可能会再次获得该消息副本。

这被称为“⾄少⼀次传递”,因此,⽤户的应⽤程序应该设计为幂等的应⽤程序(即,如果应⽤程序多次处理同⼀条消息,则不得受到不利影响)。

消息较少时单次消费不能获取指定数量的消息 从消息队列中消费消息时,DMS每次从部分消息存储分区中读取消息返回消息给消费者,如果队列中的消息数⽐较少,则单次消费可能会少于指定条数,但多次消费最终可获取全部消息。

功能与优点解耦弹性伸缩冗余存储流量削峰异步通信数据同步1,解耦我们作为A系统开发,当A系统处于1时刻的时候他只需需要向系统B与系统C提供相应的数据,但是因为某些原因B系统需要被D系统替代,那么我们要在A代码中去掉B系统的换成C系统。

⽐如后来下游数据系统⼜出现问题,那么我们是不是⼜要更改代码。

但是我们可以直接发数据发送给相应的消息队列,然后让BCD。

RabbitMQ-消息中间件协议(AMQP,MQTT,OpenMessage,Kafka)

RabbitMQ-消息中间件协议(AMQP,MQTT,OpenMessage,Kafka)

RabbitMQ-消息中间件协议
(AMQP,MQTT,OpenMessage,Kafka)
消息中间件常⽤协议
消息中间件的协议,都是基于tcp/ip,或者是udp协议。

但是单纯的tcp/ip,或者是udp⽆法满⾜消息队列的功能,因此在此基础上发展出下⾯的协议。

(尽管HTTP协议也是基于tcp/ip,或者是udp,但依然不采⽤,理由见下⽂)
AMQP(⾼级消息队列协议)
特点:
⽀持分布式
rabbitMQ和ActiveMQ⽀持该协议
MQTT(消息队列遥测传输协议)
特点:
适⽤物联⽹
低宽带,⽹络不稳定状况
rabbitMQ和ActiveMQ⽀持该协议(但是默认关闭⽀持,需要⼿动打开)
OpenMessage协议
Kafka协议
特点:
⼆进制协议,效率极好
不⽀持事务
⾯试题:为什么消息中间件不直接使⽤http协议呢?。

消息中间件 术语

消息中间件 术语

消息中间件术语消息中间件(Messaging Middleware)是指用于不同应用程序或组件之间进行通信和传递消息的软件工具。

它充当了应用程序之间的桥梁,使得它们可以高效地进行信息交流和协作。

消息中间件通过提供一种异步、可靠和可扩展的通信机制,帮助不同的应用程序实现解耦和可靠性。

消息中间件的核心概念包括消息、生产者、消费者和代理。

消息是信息的载体,可以是文本、对象或二进制数据。

生产者是消息的发送者,负责将消息发送到消息中间件。

消费者是消息的接收者,负责从消息中间件中获取消息并进行处理。

代理是消息中间件的核心组件,负责接收、存储和转发消息。

消息中间件的一个重要特性是异步通信。

在传统的同步通信方式中,发送者和接收者必须同时在线才能进行通信,这对于分布式系统来说是一种限制。

而异步通信则解决了这个问题,发送者和接收者可以分别独立地进行操作,通过消息中间件来传递消息。

这种方式可以提高系统的灵活性和可伸缩性。

另一个重要特性是可靠性。

消息中间件通常会提供消息持久化机制,即使在消息发送或接收过程中出现故障,消息也能够得到保存并在故障恢复后重新发送。

这种机制可以确保消息的可靠传递,避免消息的丢失或重复处理。

消息中间件还可以实现发布-订阅模式(Publish-Subscribe),这是一种常见的消息传递模式。

在发布-订阅模式中,生产者将消息发布到主题(Topic)上,而多个消费者可以订阅这个主题并同时接收消息。

这种模式可以实现一对多的消息传递,适用于广播和通知场景。

除了发布-订阅模式,消息中间件还支持点对点模式(Point-to-Point)。

在点对点模式中,生产者将消息发送到队列(Queue)中,而消费者通过从队列中获取消息来接收。

这种模式适用于任务分发和负载均衡等场景。

消息中间件的另一个重要应用是事件驱动架构(Event-Driven Architecture)。

在事件驱动架构中,系统的各个组件通过发送和接收事件来进行协作。

常见的中间件有哪些?

常见的中间件有哪些?

常见的中间件有哪些?世界著名的资讯机构GigaGroup把中间件分为三大类,共十五种。

另一家世界著名的资讯机构IDC同时指出,最近几年到未来的2002年,增长率最高的中间件将集中在数据存取中间件、消息中间件、交易中间件、对象中间件、应用服务器中间件5种。

·数据访问中间件适用于应用程序与数据源之间的互操作模型,客户端使用面向数据库的API,以提请直接访问和更新基于服务器的数据源,数据源可以是关系型、非关系型和对象型。

这类中间件大都基于SQL语句,采用同步通讯方式。

此类中间件使应用开发简单,但如果是透过广域网使用,会带来严重的效率问题,因为在低速网上来回交互SQL语句会使通讯流量过大,同时对数据压缩、加密带来不便。

·消息中间件消息中间件适用于需要进行网络通信的系统上,负责建立网络通信的逻辑通道,由消息中间件实现数据或文件发送。

消息中间件的一个重要作用是可以实现跨平台操作,越来越多的分布式应用采用消息中间件来构建,通过消息中间件来把应用扩展到不同的操作系统和不同的网络环境中间件领域目前最热门的技术是异步的消息中间件,异步中间件技术比同步中间件技术具有更强的容错性,在系统故障时可以保证消息的正常传输,因而在过去的两年里增长迅速。

·交易中间件交易中间件是专门针对联机交易处理系统而设计的。

交易中间件就是一组程序模块,用以大大减少开发一个联机交易处理系统所需的编程量。

交易中间件的主要标准是X/OPEN组织定义的分布式交易处理参考模型。

交易中间件理论上相对成熟,功能和性能界定清晰,但基本上适用于联机交易系统,如银行业务系统、定票系统等。

交易中间件管理由应用声明和提交的交易,并通过两阶段提交协议等方式保证分布式交易的完整性、控制并发、实现交易路由和均衡负载。

·对象中间件面向对象的中间件提供一个标准的构件框架,能使不同的厂家的软件通过不同的地址空间、网络和操作系统互相交互访问。

主流消息中间件架构分析

主流消息中间件架构分析

主流消息中间件架构分析Kafka首先还是来看Kafka的系统架构(做消息中间件逃不开要去了解Kafka)。

Kafka ecosystem包含以下几块内容:•Producer•Consumer•Kafka cluster•ZooKeeper其中ZooKeeper承当了NameServer的角色,同时用于保存系统的元数据,提供选主、协调等功能。

Broker是真正的服务端,用于存储消息。

可用性首先看外部依赖的可用性。

如果你的系统“强依赖”了外部的其他服务,那么你的系统的可用性必然和外部服务的可用性相关。

(强依赖表示不可脱离依赖的服务保持正常运行)从上面的架构可以看出Kafka只是依赖了ZooKeeper,而ZooKeeper本身是高可用的(2N+1个节点的ZK集群可以容忍N个节点故障),所以不会对整个集群的可用性造成影响。

接着看Kafka自身的可用性。

谈可用性必然就会涉及到备份问题,没有备份就意味着存在单点问题,也就没有高可用可言了。

所以我们具体来看一下Kafka的备份策略。

Kafka Replication的数据流如上图所示,从图中可以得到的一些信息:1. 分区是有备份的,如topic1-part1上图中有3个2. 分区的备份分布在不同的Broker上,上图中topic1-part1分布在broker1、broker2、broker3上,其中broker1上的为Leader3. 分区的Leader是随机分布的,上图中topic1-part1的Leader在broker1,topic2-part1的Leader在Broker上,topic3-part1的Leader的Broker4上4. 消息写入到Leader分区,之后通过Leader分区复制到Follower分区Kafak这样的Replication策略,保证了任何一个Broker出现故障时,系统依旧是可用的。

如broker1出现故障,此时会重新选举topic1-part1的Leader,之后可能是broker2或者broker3上的topic1-part1成为Leader然后负责消息的写入。

消息中间件概述

消息中间件概述

消息中间件概述什么是消息中间件?消息中间件(MQ)的定义其实并没有标准定义。

⼀般认为,消息中间件属于分布式系统中⼀个⼦系统,关注于数据的发送和接收,利⽤⾼效可靠的异步消息传递机制对分布式系统中的其余各个⼦系统进⾏集成。

⾼效:对于消息的处理处理速度快。

可靠:⼀般消息中间件都会有消息持久化机制和其他的机制确保消息不丢失。

异步:指发送完⼀个请求,不需要等待返回,随时可以再发送下⼀个请求,既不需要等待。

⼀句话总结,我们消息中间件不⽣产消息,只是消息的搬运⼯。

为什么要⽤消息中间件?假设⼀个电商交易的场景,⽤户下单之后调⽤库存系统减库存,然后需要调⽤物流系统进⾏发货,如果交易、库存、物流是属于⼀个系统的,那么就是接⼝调⽤。

但是随着系统的发展,各个模块越来越庞⼤、业务逻辑越来越复杂,必然是要做服务化和业务拆分的。

这个时候就需要考虑这些系统之间如何交互,⼀般的处理⽅式就是RPC(Remote Procedure Call)(具体实现dubbo,SpringCloud)。

系统继续发展,可能⼀笔交易后续需要调⽤⼏⼗个接⼝来执⾏业务,⽐如还有风控系统、短信服务等等。

这个时候就需要消息中间件登场来解决问题了。

所以消息中间件主要解决分布式系统之间消息的传递,同时为分布式系统中其他⼦系统提供了松耦合的架构,同时还有以下好处: 低耦合 低耦合,不管是程序还是模块之间,使⽤消息中间件进⾏间接通信。

异步通信能⼒ 异步通信能⼒,使得⼦系统之间得以充分执⾏⾃⼰的逻辑⽽⽆需等待。

缓冲能⼒ 缓冲能⼒,消息中间件像是⼀个巨⼤的蓄⽔池,将⾼峰期⼤量的请求存储下来慢慢交给后台进⾏处理,对于秒杀业务来说尤为重要。

伸缩性 伸缩性,是指通过不断向集群中加⼊服务器的⼿段来缓解不断上升的⽤户并发访问压⼒和不断增长的数据存储需求。

就像弹簧⼀样挂东西⼀样,⽤户多,伸⼀点,⽤户少,浅⼀点,啊,不对,缩⼀点。

是伸缩,不是深浅。

衡量架构是否⾼伸缩性的主要标准就是是否可⽤多台服务器构建集群,是否容易向集群中添加新的服务器。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

市场上的消息中间件: mom4j mom4j是一个完全实现JMS1.1规范的消息中间件并且向下兼容JMS1.0与1.02.它提供了自己的消息处理存储使它独立于关系数据与语言,所以它的客户端可以用任何语言开发.

OpenJMS

OpenJMS是一个开源的Java Message Service API 1.0.2 规范的实现,它包含有以下特性: *. 它既支持点到点(point-to-point)(PTP)模型和发布/订阅(Pub/Sub)模型。 *. 支持同步与异步消息发送 *. JDBC持久性管理使用数据库表来存储消息 *. 可视化管理界面。 *. Applet支持。 *. 能够与Jakarta Tomcat这样的Servlet容器结合。 *. 支持RMI, TCP, HTTP 与SSL协议。 *. 客户端验证 *. 提供可靠消息传输、事务和消息过滤

UberMQ

UberMQ完全实现了Java Message Service 规范。UberMQ是因为现有的许多JMS提供商已经违背了分布式计算的核心原则:快速与简单而开发的。 Hermes JMS

利用它提供的Swing UI可以很好的实现监控JMS providers。 ActiveMQ

ActiveMQ是一个开放源码基于Apache 2.0 licenced 发布并实现了JMS 1.1。它能够与Geronimo,轻量级容器和任Java应用程序无缝的给合。

Somnifugi

Somnifugi使得工作在同一个java虚拟机中的线程能实现消息互发。 MantaRay

MantaRay基于peer-2-peer 技术。它具有以下特性: 1.它既支持点对点(point-to-point)的域,又支持发布/订阅(publish/subscribe)类型的域。 2.并且提供对下列类型的支持:经认可的消息传递,事务型消息的传递,一致性消息和具有持久性的订阅者支持。 3.消息过滤体制。 4.能与WebLogic and WebSphere 给合。 5.支持TCP, UDP 与 HTTP传输协。 Presumo Presumo也是一个实现Java Message Service API的JMS消息中间件。 JORAM

JORAM一个类似于openJMS分布在ObjectWeb之下的JMS消息中间件。 JMS4Spread

JMS4Spread是一个消息系统.它部分地实现了Java消息服务(JMS) API. Open Message Queue

Open Message Queue是Sun Java System Message Queue的一个开源版本。Open message queue是一个企业级,可升级,非常成熟的消息服务器。它为面向消息的系统集成提供一套完整的JMS(Java Message Service )实现。由于Open MQ源自Sun的Java Message Queue,所以其具有Java System Message Queue拥有的所有特性,功能和性能 。

FFMQ

FFMQ是一个轻量级,高性能,快速的Native JMS1.1开源实现。支持SSL远程连接,自动防故障的持久化机制,基于模板定义目的地(Destination),采用模式匹配自动创建目的地(Destination)。

MQSSave/MQSLoad

MQSSave是一个简单的Java程序,能够读取MQSeries队列的消息保存至文件中。而MQSLoad是一相反的Java程序,能够读取文件中的消息然后加载至MQSeries队列中。

HornetQ

HornetQ是一个支持集群和多种协议,可嵌入、高性能的异步消息系统。HornetQ完全支持JMS,HornetQ不但支持JMS1.1 API同时也定义属于自己的消息API,这可以最大限度的提升HornetQ的性能和灵活性。在不久的将来更多的协议将被HornetQ支持。  HornetQ拥有超高的性能,HornetQ在持久化消息方面的性能可以轻易的超于其它常见的非持久化消息引擎的性能。当然,HornetQ的非持久化消息的性能会表现的更好!  HornetQ完全使用POJO,纯POJO的设计让HornetQ可以尽可能少的以来第三方的包。从设计模式来说,HornetQ这样的设计入侵性也最小。HornetQ既可以独立运行,也可以与其它Java应用程序服务器集成使用。  HornetQ拥有完善的错误处理机制,HornetQ提供服务器复制和故障自动转移功能,该功能可以消除消息丢失或多个重复信息导致服务器出错。  HornetQ提供了灵活的集群功能,通过创建HornetQ集群,您可以享受到到消息的负载均衡带来的性能提升。您也可以通过集群,组成一个全球性的消息网络。您也可以灵活的配置消息路由。  HornetQ拥有强大的管理功能。HornetQ提供了大量的管理API和监控服务器。它可以无缝的与应用程序服务器整合,并共同工作在一个HA环境中。

Apache Qpid Apache Qpid是最新开放企业信息标准AMQP(Advanced Message Queuing Protocol)的一个开源实现。Java版实现完全支持JMS标准,可运行在任意Java平台上。此外Qpid还提供AMQP Client APIs的各种语言实现包括:  C++  Java, fully conformant with JMS 1.1  C# .NET, 0-10 using WCF  Ruby  Python

Spring AMQP

Spring AMQP是一个用于替换原先Spring JMS支持的消息解决方案。提供收发消息的模板,还支持基于消息驱动的POJO。用法和配置与Spring中对JMS的支持一样。这个项目包含Java和.NET两个版本。

Kafka

Kafka是一个高吞吐量分布式消息系统。linkedin开源的kafka。 Kafka就跟这个名字一样,设计非常独特。首先,kafka的开发者们认为不需要在内存里缓存什么数据,操作系统的文件缓存已经足够完善和强大,只要你不搞随机写,顺序读写的性能是非常高效的。kafka的数据只会顺序append,数据的删除策略是累积到一定程度或者超过一定时间再删除。Kafka另一个独特的地方是将消费者信息保存在客户端而不是MQ服务器,这样服务器就

不用记录消息的投递过程,每个客户端都自己知道自己下一次应该从什么地方什么位置读取消息,消息的投递过程也是采用客户端主动pull的模型,这样大大减轻了服务器的负担。Kafka还强调减少数据的序列化和拷贝开销,它会将一些消息组织成Message Set做批量

存储和发送,并且客户端在pull数据的时候,尽量以zero-copy的方式传输,利用sendfile(对应java里的 FileChannel.transferTo/transferFrom)这样的高级IO函数来减少拷贝开销。可见,kafka是一个精心设计,特定于某些应用的MQ系统,这种偏向特定领域的MQ系统我估计会越来越多,垂直化的产品策略值的考虑。 play-rabbitmq 这是Play! Framework开发框架的一个扩展模块。用于生产和消费RabbitMQ消息。 队列消息系统 FQueue

FQueue是一个高性能、基于磁盘持久存储的队列消息系统。兼容memcached协议,能用memcached的语言都可以良好的与它通信。 FQueue为你提供一个不需要特别优化,高性能的一个消息系统。

特性 1. 基于磁盘持久化存储。 2. 支持memcached协议。 3. 支持多队列,密码验证功能。 4. 高性能,能达到数十万qps。 5. 低内存消耗。100-300M内存即可工作得很好。 6. 高效率IO读写算法,IO效率高。 7. 纯JAVA代码。支持进程内JVM级别的直接调用。 8. 在不需要强顺序的场景下,支持多机负载均衡。 不支持 1. 不支持topic方式的订阅功能。 2. 不支持主从复制。

主流消息中间件及选型推荐: ActiveMQ:(还有升级版叫Apollo, 由于转向Scala,原来的架构都要改掉。但是只支持storm协议,不支持JMS),在网络上别人反映,消息量越来越大时,当出现消息堆积时,性能争骤下降,主要卡在磁盘写入,用了硬件加速,也还是不能忍受。

消息中间件的技术选型心得-RabbitMQ、ActiveMQ和ZeroMQ 作者:chszs,转载需注明。博客主页:http://blog.csdn.net/chszs RabbitMQ、ActiveMQ和ZeroMQ都是极好的消息中间件,但是我们在项目中该选择哪个更适合呢?很多开发者面临这个烦恼。下面我会对这三个消息中间件做一个比较,看了后你们就心中有数了。

RabbitMQ是AMQP协议领先的一个实现,它实现了代理(Broker)架构,意味着消息在发送到客户端之前可以在中央节点上排队。此特性使得RabbitMQ易于使用和部署,适宜于很多场景如路由、负载均衡或消息持久化等,用消息队列只需几行代码即可搞定。但是,这使得它的可扩展性差,速度较慢,因为中央节点增加了延迟,消息封装后也比较大。

ZeroMQ是一个非常轻量级的消息系统,专门为高吞吐量/低延迟的场景开发,在金融界的应用中经常可以发现它。与RabbitMQ相比,ZeroMQ支持许多高级消息场景,但是你必须实现ZeroMQ框架中的各个块(比如Socket或Device等)。ZeroMQ非常灵活,但是你必须学习它的80页的手册(如果你要写一个分布式系统,一定要阅读它)。

相关文档
最新文档