消息队列是分布式应用间交换信息的重要组件,消息队列可驻留在内存或磁盘上, 队列能够存储消息直到它们被应用程序读走。node
经过消息队列,应用程序能够在不知道彼此位置的状况下独立处理消息,或者在处理消息前不须要等待接收此消息。算法
因此消息队列能够解决应用解耦、异步消息、流量削锋等问题,是实现高性能、高可用、可伸缩和最终一致性架构中不能够或缺的一环。apache
如今比较常见的消息队列产品主要有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、RocketMQ等。编程
ActiveMQ 是Apache出品,最流行的,能力强劲的开源消息总线。ActiveMQ 是一个彻底支持JMS1.1和J2EE 1.4规范的 JMS Provider实现,尽管JMS规范出台已是好久的事情了,可是JMS在当今的J2EE应用中间仍然扮演着特殊的地位。api
ActiveMQ特性以下:浏览器
⒈ 多种语言和协议编写客户端。语言: Java,C,C++,C#,Ruby,Perl,Python,PHP。应用协议: OpenWire,Stomp REST,WS Notification,XMPP,AMQP服务器
⒉ 彻底支持JMS1.1和J2EE 1.4规范 (持久化,XA消息,事务)网络
⒊ 对Spring的支持,ActiveMQ能够很容易内嵌到使用Spring的系统里面去,并且也支持Spring2.0的特性session
⒋ 经过了常见J2EE服务器(如 Geronimo,JBoss 4,GlassFish,WebLogic)的测试,其中经过JCA 1.5 resource adaptors的配置,可让ActiveMQ能够自动的部署到任何兼容J2EE 1.4 商业服务器上数据结构
⒌ 支持多种传送协议:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
⒍ 支持经过JDBC和journal提供高速的消息持久化
⒎ 从设计上保证了高性能的集群,客户端-服务器,点对点
⒏ 支持Ajax
⒐ 支持与Axis的整合
⒑ 能够很容易得调用内嵌JMS provider,进行测试
RabbitMQ是流行的开源消息队列系统,用erlang语言开发。RabbitMQ是AMQP(高级消息队列协议)的标准实现。支持多种客户端,如:Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等,支持AJAX,持久化。用于在分布式系统中存储转发消息,在易用性、扩展性、高可用性等方面表现不俗。
几个重要概念:
Broker:简单来讲就是消息队列服务器实体。
Exchange:消息交换机,它指定消息按什么规则,路由到哪一个队列。
Queue:消息队列载体,每一个消息都会被投入到一个或多个队列。
Binding:绑定,它的做用就是把exchange和queue按照路由规则绑定起来。
Routing Key:路由关键字,exchange根据这个关键字进行消息投递。
vhost:虚拟主机,一个broker里能够开设多个vhost,用做不一样用户的权限分离。
producer:消息生产者,就是投递消息的程序。
consumer:消息消费者,就是接受消息的程序。
channel:消息通道,在客户端的每一个链接里,可创建多个channel,每一个channel表明一个会话任务。
消息队列的使用过程,以下:
(1)客户端链接到消息队列服务器,打开一个channel。
(2)客户端声明一个exchange,并设置相关属性。
(3)客户端声明一个queue,并设置相关属性。
(4)客户端使用routing key,在exchange和queue之间创建好绑定关系。
(5)客户端投递消息到exchange。
exchange接收到消息后,就根据消息的key和已经设置的binding,进行消息路由,将消息投递到一个或多个队列里。
号称史上最快的消息队列,它实际相似于Socket的一系列接口,他跟Socket的区别是:普通的socket是端到端的(1:1的关系),而ZMQ倒是能够N:M 的关系,人们对BSD套接字的了解较多的是点对点的链接,点对点链接须要显式地创建链接、销毁链接、选择协议(TCP/UDP)和处理错误等,而ZMQ屏蔽了这些细节,让你的网络编程更为简单。ZMQ用于node与node间的通讯,node能够是主机或者是进程。
引用官方的说法: “ZMQ(如下ZeroMQ简称ZMQ)是一个简单好用的传输层,像框架同样的一个socket library,他使得Socket编程更加简单、简洁和性能更高。是一个消息处理队列库,可在多个线程、内核和主机盒之间弹性伸缩。ZMQ的明确目标是“成为标准网络协议栈的一部分,以后进入Linux内核”。如今还未看到它们的成功。可是,它无疑是极具前景的、而且是人们更加须要的“传统”BSD套接字之上的一 层封装。ZMQ让编写高性能网络应用程序极为简单和有趣。”
特色是:
高性能,非持久化
跨平台:支持Linux、Windows、OS X等
多语言支持; C、C++、Java、.NET、Python等30多种开发语言
可单独部署或集成到应用中使用
可做为Socket通讯库使用
与RabbitMQ相比,ZMQ并不像是一个传统意义上的消息队列服务器,事实上,它也根本不是一个服务器,更像一个底层的网络通信库,在Socket API之上作了一层封装,将网络通信、进程通信和线程通信抽象为统一的API接口。支持“Request-Reply “,”Publisher-Subscriber“,”Parallel Pipeline”三种基本模型和扩展模型。
ZeroMQ高性能设计要点:
一、无锁的队列模型
对于跨线程间的交互(用户端和session)之间的数据交换通道pipe,采用无锁的队列算法CAS;在pipe两端注册有异步事件,在读或者写消息到pipe的时,会自动触发读写事件。
二、批量处理的算法
对于传统的消息处理,每一个消息在发送和接收的时候,都须要系统的调用,这样对于大量的消息,系统的开销比较大,zeroMQ对于批量的消息,进行了适应性的优化,能够批量的接收和发送消息。
三、多核下的线程绑定,无须CPU切换
区别于传统的多线程并发模式,信号量或者临界区, zeroMQ充分利用多核的优点,每一个核绑定运行一个工做者线程,避免多线程之间的CPU切换开销。
Kafka是一种高吞吐量的分布式发布订阅消息系统,它能够处理消费者规模的网站中的全部动做流数据。 这种动做(网页浏览,搜索和其余用户的行动)是在现代网络上的许多社会功能的一个关键因素。 这些数据一般是因为吞吐量的要求而经过处理日志和日志聚合来解决。 对于像Hadoop的同样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。Kafka的目的是经过Hadoop的并行加载机制来统一线上和离线的消息处理,也是为了经过集群机来提供实时的消费。
Kafka是一种高吞吐量的分布式发布订阅消息系统,有以下特性:
经过O(1)的磁盘数据结构提供消息的持久化,这种结构对于即便数以TB的消息存储也可以保持长时间的稳定性能。(文件追加的方式写入数据,过时的数据按期删除)
高吞吐量:即便是很是普通的硬件Kafka也能够支持每秒数百万的消息
支持经过Kafka服务器和消费机集群来分区消息
支持Hadoop并行数据加载
Kafka相关概念
Kafka集群包含一个或多个服务器,这种服务器被称为broker[5]
每条发布到Kafka集群的消息都有一个类别,这个类别被称为Topic。(物理上不一样Topic的消息分开存储,逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic便可生产或消费数据而没必要关心数据存于何处)
Parition是物理上的概念,每一个Topic包含一个或多个Partition.
负责发布消息到Kafka broker
消息消费者,向Kafka broker读取消息的客户端。
每一个Consumer属于一个特定的Consumer Group(可为每一个Consumer指定group name,若不指定group name则属于默认的group)。
通常应用在大数据日志处理或对实时性(少许延迟),可靠性(少许丢数据)要求稍低的场景使用。
RocketMQ是阿里开源的消息中间件,纯Java开发,具备高吞吐量、高可用性、适合大规模分布式系统应用的特色。RocketMQ思路起源于Kafka,但并非简单的复制,它对消息的可靠传输及事务性作了优化,目前在阿里集团被普遍应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景,支撑了阿里屡次双十一活动。
由于是阿里内部从实践到产品的产物,所以里面不少接口、api并非很广泛适用。可靠性毋庸置疑,并且与Kafka一脉相承(甚至更优),性能强劲,支持海量堆积。
Apache ActiveMQ 是一个很是流行、强大、开源的消息和集成模式(Integration Patterns)服务器,速度快、支持多种跨语言客户端和协议,易于使用企业集成模式(Enterprise Integration Patterns),拥有许多先进的特性,彻底支持JMS 1.1和J2EE 1.4规范。ActiveMQ 基于Apache 2.0许可。
Apollo 以 ActiveMQ原型为基础,是一个更快、更可靠、更易于维护的消息代理工具。Apache 号称 Apollo 为最快、最强健的STOMP(Streaming Text Orientated Message Protocol,流文本定向消息协议)服务器。
Apollo的特性以下:
到底应该哪一个方案,仍是要看具体的需求。在咱们的设计中,MQ的功能与业务无关,所以优先考虑使用已有的中间件搭建。那么具本选择哪一个中间件呢?先来梳理下咱们对MQ的需求:
如前文所述,除了最基本生产消费模型,还须要MQ能支持REQUEST-REPLY模型,以提供对同步调用的支持。 此外,若是MQ能提供PUBLISH-SUBSCRIBE模型,则事件代理的实现能够更加简单。
考虑将来一到两年内产品的发展,消息队列的呑吐量预计不会超过 1W qps,但由单条消息延迟要求较高,但愿尽可能的短。
由于是在线服务,所以须要较高的可用性,但充许有少许消息丢失。
包括学习成本、初期的开发部署成本、平常的运维成本等。
ActiveMQ与RabbitMQ在不少方面都很类似,但ActiveMQ对非JAVA生态的支持不及rabbitMQ, 加之精力有限,所以本文重点关注RabbitMQ。
特性 | ActiveMQ | RabbitMQ | Kafka | RocketMQ |
PRODUCER-COMSUMER | 支持 | 支持 | 支持 | 支持 |
PUBLISH-SUBSCRIBE | 支持 | 支持 | 支持 | 支持 |
REQUEST-REPLY | 支持 | 支持 | - | 支持 |
API完备性 | 高 | 高 | 高 | 低(静态配置) |
多语言支持 | 支持,JAVA优先 | 语言无关 | 支持,JAVA优先 | 支持 |
单机呑吐量 | 万级 | 万级 | 十万级 | 单机万级 |
消息延迟 | - | 微秒级 | 毫秒级 | - |
可用性 | 高(主从) | 高(主从) | 很是高(分布式) | 高 |
消息丢失 | - | 低 | 理论上不会丢失 | - |
消息重复 | - | 可控制 | 理论上会有重复 | - |
文档的完备性 | 高 | 高 | 高 | 中 |
提供快速入门 | 有 | 有 | 有 | 无 |
首次部署难度 | - | 低 | 中 | 高 |
注: - 表示还没有查找到准确数据
消息队列的选型须要根据具体应用需求而定,ZeroMQ小而美,RabbitMQ大而稳,Kakfa和RocketMQ快而强劲。
RocketMQ虽然目前还不少不完善,可是一旦在Apache孵化成为顶级项目,前途也是不可限量的。
https://blog.csdn.net/cws1214/article/details/52922267
https://blog.csdn.net/liuxinghao/article/details/60875715
https://blog.csdn.net/pkueecser/article/details/50613989
做者:朝雨忆轻尘
出处:https://www.cnblogs.com/xifengxiaoma/ 版权全部,欢迎转载,转载请注明原文做者及出处。