标签:设计 关系 企业级 相对 集合 分类 超过 series 系统
MQ全称为Message Queue,消息队列(MQ)是一种应用程序的通信方法。应用程序通过写和检索出入列的针对应用程序的数据(消息)来通信,而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信,而不是通过直接调用彼此来通信,直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求.。
MQ的消费-生产者模型的一个典型的代表,一端往消息队列中不断的写入消息,而另一端则可以读取或订阅列队中的消息。MQ和JMS类似,但不同的是JMS是SUN JAVA消息中间件服务的一个标准和API定义,而MQ则是遵循AMQP协议的具体实现和产品。
是使用Erlang编写的一个开源的消息队列,本身支持很多的协议:AMQP,XMPP, SMTP, STOMP,也正是如此,使的它变的非常重量级,更适合于企业级的开发。同时实现了一个经纪人(Broker)构架,这意味着消息在发送给客户端时先在中心队列排队。对路由(Routing),负载均衡(Load balance)或者数据持久化都有很好的支持。
是一个Key-Value的NoSQL数据库,开发维护很活跃,虽然它是一个Key-Value数据库存储系统,但它本身支持MQ功能,所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作,各执行100万次,每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明:入队时,当数据比较小时Redis的性能要高于RabbitMQ,而如果数据大小超过了10K,Redis则慢的无法忍受;出队时,无论数据大小,Redis都表现出非常好的性能,而RabbitMQ的出队性能则远低于Redis。
|
入队 |
出队 |
||||||
|
128B |
512B |
1K |
10K |
128B |
512B |
1K |
10K |
Redis |
16088 |
15961 |
17094 |
25 |
15955 |
20449 |
18098 |
9355 |
RabbitMQ |
10627 |
9916 |
9370 |
2366 |
3219 |
3174 |
2982 |
1588 |
号称最快的消息队列系统,尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列,但是开发人员需要自己组合多种技术框架,技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式,你不需要安装和运行一个消息服务器或中间件,因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库,可以使用NuGet安装,然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列,也就是说如果down机,数据将会丢失。其中,Twitter的Storm中使用ZeroMQ作为数据流的传输。
是Apache下的一个子项目。 类似于ZeroMQ,它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ,它少量代码就可以高效地实现高级应用场景。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。
Kafka是Apache下的一个子项目,是一个高性能跨语言分布式Publish/Subscribe消息队列系统,而Jafka是在Kafka之上孵化而来的,即Kafka的一个升级版。具有以下特性:快速持久化,可以在O(1)的系统开销下进行消息持久化;高吞吐,在一台普通的服务器上既可以达到10W/s的吞吐速率;完全的分布式系统,Broker、Producer、Consumer都原生自动支持分布式,自动实现复杂均衡;支持Hadoop数据并行加载,对于像Hadoop的一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制来统一了在线和离线的消息处理,这一点也是本课题所研究系统所看重的。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统,除了性能非常好之外,还是一个工作良好的分布式系统。
其他一些队列列表HornetQ、Apache Qpid、Sparrow、Starling、Kestrel、Beanstalkd、Amazon SQS就不再一一分析。
JMS即java消费服务应用程序接口是一个java平台中关于面向消息中间件的API,用于在两个应用程序之间,或分布式系统中发送消息,进行异步通讯。java消息服务是一个与具体平台无关的API,绝大多数MOM提供商都对JMS提供支持。
JMS是java平台上有关面向消息中间件的技术规范,它便于消息系统中的java应用程序进行消息交换,并且通过提供标准的产生,发送,接受消息的接口简化企业应用的开发。
简介:
JMS是一种与厂商无关的API,用来访问消息收发系统。它类似于JDBC:这里,JDBC是可以用来访问许多不同关系数据库的API,而JMS则提供同样与厂商无关的访问方法,以访问消息收发服务。许多厂商目前都支持JMS,包括IBM的MQSeries,BEA的Weblogic JMS service和Progress的SonicMQ。JMS能够通过消息收发服务从一个JMS客户机向另一个JMS客户机发送消息。消息是JMS中的一种类型对象,有两部分组成:报头和消息主体。报头由路由信息以及有关该消息的元数据组成。消息主体则携带着应用程序的数据或有效负载。根据有效负载的类型来划分,可以将消息分为几种类型,它们分别携带:简单文本(TextMessage),可序列化的对象(ObjectMessage),属性集合(MapMessage),字节流(BytesMessage),原始值流(StreamMessage),还有无有效负载的消息(Message)。
JMS是一个用于提供消息服务的技术规范,它制定了在整个消息服务提供过程中的所有数据结构个交互流程。而MQ则是消息队列服务,是面向消息中间件的最终实现,是真正的服务提供者;消息中间件的实现可以基于JMS,也可以基于其他规范或标准。
支持JMS的开源MQ:
ActiveMQ是Apache出品,最流行的,能力强劲的开源消息总线,ActiveMQ是一个完全支持JMS1.1和J2EE1.4规范的JMS Provider实现。
1.多种语言和协议编写客户端。语言:java,C,C++,C#,Ruby,Perl,Python,PHP;
2.完全支持JMS1.1和J2EE1.4规范(持久化,XA消息,事务);
3.对spring的支持,ActiveMQ可以很容易内嵌到使用spring的系统里去,而且也支持spring2.0的特性;
4.通过了常见的J2EE服务器的测试,其中通过JCA1.5 resource adaptors的配置,可以让ActiveMQ可以自动部署到任何兼容J2EE1.4商业服务器上;
5.支持多种传送协议:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA;
6.支持通过JDBC和journal提供高速的消息持久化;
7.从设计上保证了高性能的集群,客户端-服务器,点对点;
8.支持ajax;
9.支持axis的整合;
10.可以很容易得调用内嵌JMS provider进行测试;
11.ActiveMQ速度非常快,一般要比JbossMQ快10倍;
是一个快速的开源消息组件,支持集群,自动检测,TCP,SSL,广播,持久化,XA和J2EE1.4容器无缝结合,并且支持轻量级容器和大多数跨语言客户端上的java虚拟机。消息异步接收,减少软件多系统集成的耦合度。消息可靠接收,确保消息在中间件可靠保存,多个消息也可以组成原子事务。
ActiveMQ默认的配置性能偏低,需要优化配置,但是配置文件复杂,ActiveMQ本身不提供管理工具;实例代码少;主页上的文档看上去比较全面,但是缺乏一种有效的组织方式,文档只有片段,用户很难由浅入深进行了解。
ActiveMQ中间件用java语言编写,因此自然提供java客户端API。但是ActiveMQ也是为C/C++、.NET、Perl、PHP、Python、Ruby和一些其他语言提供客户端。在你考虑如何集成不同平台不同语言编写应用的时候,ActiveMQ拥有巨大的优势。多种客户端API通过ActiveMQ发送和接收消息成为可能,无论使用的是什么语言。此外,ActiveMQ还提供交叉语言功能,该功能整个这种功能,无需使用远程过程调用。因为消息协助应用解耦。
使用RPC同步调用的应用十分普遍。使用同步请求的系统在规模上有较大的限制,因为请求会被阻塞,从而导致整个系统变慢。如果使用异步消息替代,可以很容易增加额外的消息接收者,使得消息能被并发消耗,从而加快了请求处理。
紧耦合架构可以导致很多问题,尤其是如果他们是分布的。松耦合架构,在另一方面,证实了更少的依赖性,能够更好地处理不可预见的改变,不仅可以在系统中改变组价而不影响整个系统,而且组件交互也相当简单。相比使用同步系统,异步系统能够给我们带来事件驱动架构
解耦,异步架构的系统允许通过代理器自己配置更多的客户端,内存等来扩大系统,而不是增加更多的代理器。
很多使用事件驱动设计的系统是为了获得高可扩展性。每一个服务完成一个功能并且只有一个功能。应用就通过服务组合起来,服务之间使用异步消息和最终一致性。这样的设计便可以引入一个复杂事件处理概念。使用CEP,部件之间的交互可以被记录追踪。在异步消息系统中,可以很容易在部件间增加一层处理。
1.2.1 消息队列(Queue)
1.2.2 发送者(Sender)
1.2.3 接收者(Receiver)
1.2.4 每个消息都被发送到一个特定的队列中,接受者从队列中获取消息。队列保留着消息,直到它们被消费或超市;
1.3.1 每个消息只有一个消费者;
1.3.2 发送者和接收者之间在时间上没有依赖性,也就是说当发送者发送了消息之后,不管接收者有没有正在运行,它不会影响消息被发送到队列;
1.3.3 接收者在成功接收消息之后需向队列应答成功
2.2.1 主题(Topic)
2.2.2 发布者(Publisher)
2.2.3 订阅者(Subscriber)
2.2.4 客户端将消息发送到主题。多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者;
2.3.1 每个消息可以有多个消费者;
2.3.2 发布者和订阅者之间有时间上的依赖性。针对某个主题(Topic)的订阅者,它必须创建一个订阅者之后,才能消费发布者的消息,而且为了消费消息,订阅者必须保持运行的状态;
2.3.3 为了缓和这样严格的时间相关性,JMS允许订阅者创建一个可持久化的订阅。这样,及时订阅者没有被激活(运行),它也能接收到发布者的消息;
标签:设计 关系 企业级 相对 集合 分类 超过 series 系统
原文地址:https://www.cnblogs.com/mayuan01/p/12391321.html