MQ介绍与选型
MQ600电动机使用说明书
Iqdgc 为启动时间过长的电流定值，Iφ为相电流。
2、对于增安型电动机的 Ts 时间设定值应不大于 1.7 倍 tE 时间。即对于增安型电动机起动
时间设置最大为：Ts=1.7 ×tE s
其中：tE 时间为交流绕组在最高环境温度下达到额定运行稳定温度后，从开始通过堵转电流
IA 时计起直至上升到极限温度所需的时间（以增安型电动机铭牌数据为准）
本装置适用于交流 50HZ，额定电压 AC380V/660V，额定电流在 800A 的交流异步电动机，广泛用于电力、石化、轻工、煤炭、 纸业、钢铁、冶金、纺织等行业。
产品符合以下标准的相关要求：
GB/T 14048.1 -2000 GB/T 14048.4-2003 IEC60947-4-1：2000
功能配置 标准配置
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
MQ600 系列产品选型说明书定值设车源自故障信息 启动参数设定 系统参数设定
电能 三相三线与三相四线设置切换 各种保护定值查询、整定 实时查询故障/报警信息 控制权限、启动等参数查询、整定 地址、拨特率、电机额定值等参数查询、整定
其动作条件如下：
● Ua>Uh
Uh 为过电压定值。
● T>Th
Th 为过电压延时定值
轻载保护
MQ600 系列产品选型说明书
湖南利达电子电器厂
电机欠载运行时，由于功率因素较低，因此电流可能不一定会很小；欠功率保护根据电机的有功功率进行保护，能更好实现 欠载保护。 需设定以下参数： 欠功率整定值：45％～95％ 动作时间：0.1S～50S 动作特性：三相有功功率值<有功功率设定值*0.9. 时动作;
RocketMQ在面试中那些常见问题及答案+汇总
RocketMQ在⾯试中那些常见问题及答案+汇总1、说说你们公司线上⽣产环境⽤的是什么消息中间件?【多个mq如何选型？】2、多个mq如何选型？MQ描述RabbitMQ erlang开发，对消息堆积的⽀持并不好，当⼤量消息积压的时候，会导致 RabbitMQ 的性能急剧下降。
每秒钟可以处理⼏万到⼗⼏万条消息。
RocketMQ java开发，⾯向互联⽹集群化功能丰富，对在线业务的响应时延做了很多的优化，⼤多数情况下可以做到毫秒级的响应，每秒钟⼤概能处理⼏⼗万条消息。
Kafka Scala开发，⾯向⽇志功能丰富，性能最⾼。
当你的业务场景中，每秒钟消息数量没有那么多的时候，Kafka 的时延反⽽会⽐较⾼。
所以，Kafka 不太适合在线业务场景。
ActiveMQ java开发，简单，稳定，性能不如前⾯三个。
⼩型系统⽤也ok，但是不推荐。
推荐⽤互联⽹主流的。
3、为什么要使⽤MQ？因为项⽬⽐较⼤，做了分布式系统，所有远程服务调⽤请求都是同步执⾏经常出问题，所以引⼊了mq作⽤描述解耦系统耦合度降低，没有强依赖关系异步不需要同步执⾏的远程调⽤可以有效提⾼响应时间削峰请求达到峰值后，后端service还可以保持固定消费速率消费，不会被压垮4、RocketMQ由哪些⾓⾊组成，每个⾓⾊作⽤和特点是什么？⾓⾊作⽤Nameserver⽆状态，动态列表；这也是和zookeeper的重要区别之⼀。
zookeeper是有状态的。
Producer消息⽣产者，负责发消息到Broker。
Broker就是MQ本⾝，负责收发消息、持久化消息等。
Consumer消息消费者，负责从Broker上拉取消息进⾏消费，消费完进⾏ack。
5、RocketMQ中的Topic和JMS的queue有什么区别？queue就是来源于数据结构的FIFO队列。
⽽Topic是个抽象的概念，每个Topic底层对应N个queue，⽽数据也真实存在queue上的。
6、RocketMQ Broker中的消息被消费后会⽴即删除吗？不会，每条消息都会持久化到CommitLog中，每个Consumer连接到Broker后会维持消费进度信息，当有消息消费后只是当前Consumer的消费进度（CommitLog的offset）更新了。
耐奇最新选型说明书2012版
1.2.6 免开盖调试
工作参数设置、系统状态查询均可通过“操作旋钮”或“红外设定器”完 成，无需打开电气罩，使得环境中的灰尘、潮气等有害物质不能进入执行器 的内部，极大的提高了电气控制部分的可靠性。
/智/能/型/电/动/执/行/机/构/
Page 03 04
1.2.7 掉电不丢失的状态指示
现场可组态的双稳态输出触点可指示阀门的各种状态（包括开关限位、 过转矩、运行指示或阀门开到某一位置等），即使系统掉电也可保持输 出状态不变。
1.2.8 自锁性
蜗轮与蜗杆的自锁设计防止了执行器在断电或断信号的情况下发生反转现象。
1.2.9 离合器自动复位
具有独特的机械式手动/自动切换机构，手动操作通过扳动转换手柄后实现， 电机一旦接受电信号启动，离合器能自动复位并使执行器恢复到自动状态。
产品概述
1.多回转NDQII/NDMQII
1.1 产品概述
NDQII/NDMQII多回转系列智能型电动执行器是过程控制中 非常重要的现场控制设备，它可以通过一个独立的设定器或 现场旋钮对其进行非侵入性的快速设定、检查及查询。执行 器采用点阵式液晶显示器，以中文、数字、图形等形式显示 执行器的转矩、阀门位置、限位设定等工作状态和报警。 NDQII/NDMQII系列电动执行器设计先进、结构可靠、规格 齐全，可以实现多回转任意转角输出，能在输出转矩15Nm ～3000Nm范围内提供最合理的解决方案，选配NB系列多回 转减速箱后可以达到更大多回转输出转矩要求，选配NGW系 列部分回转减速箱后可以转化成角行程600Nm～ 130000Nm范围内提供最合理的解决方案，该产品广泛应用 于电力、石油、化工、冶金、船舶、轻工食品、造纸、建 筑、市政工程、环保等领域。 NDQII/NDMQII系列电动执行器的接口法兰按照 ISO5210:2001(GB/T12222-2005)标准制造，耐奇系列电动 执行器有丰富的阀门配套经验，连接方式，更方便、可靠， 能满足各种阀门的不同连接要求。执行器箱体可适应户外工 作环境，电气防护等级IP68，以选件形式提供的、具有防爆 耐压结构的隔爆型产品则可适用于ⅡA、ⅡB、ⅡC级T1-T4级 爆炸性气体环境的1、2区场所等危险作业环境。 NDQII/NDMQII系列电动执行器，可根据用户要求，增加选 件即可附加各种功能配置，如Modbus现场总线卡、 Profibus-DP现场总线卡等，以满足各种工业过程控制的要求。 为适应各种恶劣工况，我们以NDQII/NDMQII系列电动执行 器为基础，开发出NDQII-f/NDMQII-f分体式智能型电动执 行器，它将电气控制组件装入独立控制器，从而与执行机构 控制部分分离，之间通过电缆远距离传输控制信号，进行控 制与反馈，能够实现NDQII/NDMQII系列电动执行器的全部 功能。NDQII-f/NDMQII-f分体式智能型电动执行器在高温 或者振动强烈等恶劣工况下得到广泛使用。
MQ3235门座式起重机总体计算书
MQ3235门座式起重机总体计算书1计条件与工作状况1.1设计风速工作时： 20/m s非工作时：50/m s1.2温度最高温度500C，最低温度00C。
1.3湿度相对湿度 100％1.4工作条件每天三班四倒工作制（每班7小时），每年工作天数300～320天，门机使用寿命20年。
1.5门机工作级别：利用等级 U8载荷状态 Q3工作级别 A81.6机构工作级别表1 机构工作级别1.7其它有雾气和湿热海洋性气候侵蚀。
起重机承受最大地震烈度为7度。
2设计参数3.1采用图解法确定臂架各部分的尺寸和大拉杆下铰点位置图1 初步确定的臂架尺寸和大拉杆下铰点位置图2臂架尺寸和大拉杆下铰点位置表3 臂架各部分尺寸图3 物品的水平位移①吊重全幅度水平落差应满足：max max min 4370.02()0.02(3510)0.5y h R R m ∆=<∆=-=⨯-=（满足） ②吊重全幅度未平衡力矩应满足：max 20380.10.132********Q M kN m M kN m =⋅>=⨯⨯⨯=⋅（不满足要求） ③象鼻梁端点水平速度应满足：102cos cos A r v v Lr βωβ==平 0ω—臂架摆动角速度max min 2.0952.852 2.60.735v v ==>平平（不满足） 3.2臂架系统自重平衡和合成力矩（初步估算，选配重29t ）表5 不平衡力矩表6 最大和最小不平衡力矩检验不平衡力矩：M ∆—臂架系统自重的不平衡力矩QM —吊重不平衡力矩 ① 最大幅度时 0M ∆< 且 00Q M M ∆+<（满足） 最小幅度时 0M ∆> 且 00Q M M ∆+>（满足）② max 3203511200Q M QR kNm ==⨯=max 1266.060.10.1112001120Q M kNm M kNm ∆=>=⨯=（不满足）4稳定性验算4.1.起重机各部分重心4.2.载重稳定性验算 4.2.1.第一种计算工况计算位置取起重机臂架垂直于运行轨道方向（因为轨距小于基距）、倾覆棱边在前沿轨面。
MQ选型对比RabbitMQRocketMQActiveMQKafka
MQ选型对⽐RabbitMQRocketMQActiveMQKafka⼏种MQ产品说明：ZeroMQ : 扩展性好，开发⽐较灵活，采⽤C语⾔实现，实际上他只是⼀个socket库的重新封装，如果我们做为消息队列使⽤，需要开发⼤量的代码RabbitMQ :结合erlang语⾔本⾝的并发优势，性能较好，但是不利于做⼆次开发和维护: 历史悠久的开源项⽬，已经在很多产品中得到应⽤，实现了JMS1.1规范，可以和spring-jms轻松融合，实现了多种协议，不够轻巧（源代码⽐RocketMQ多）.，⽀持持久化到数据库，对队列数较多的情况⽀持不好，不过我们的项⽬中并不会建很多的队列.ActiveMQ是Apache 下的⼀个⼦项⽬。
Redis 做为⼀个基于内存的K-V数据库，其提供了消息订阅的服务，可以当作MQ来使⽤，⽬前应⽤案例较少，且不⽅便扩展RocketMQ: 的MQ中间件，在其多个产品下使⽤，并能够撑住的⼤流量，他并没有实现JMS规范，使⽤起来很简单。
部署由⼀个命名服务（nameserver）和⼀个代理（broker）组成，nameserver和broker以及producer都⽀持集群，队列的容量受机器硬盘的限制，队列满后可以⽀持持久化到硬盘（也可以⾃⼰适配代码，将其持久化到NOSQL数据库中），队列满后会影响吞吐量，可以采⽤主备来保证稳定性，⽀持回溯消费，可以在broker端进⾏消息过滤. Kafka/Jafka Kafka是Apache下的⼀个⼦项⽬，是⼀个⾼性能跨语⾔分布式发布/订阅消息队列系统，⽽Jafka是在Kafka之上孵化⽽来的，即Kafka的⼀个升级版。
具有以下特性：快速持久化，可以在O(1)的系统开销下进⾏消息持久化；⾼吞吐，在⼀台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原⽣⾃动⽀持分布式，⾃动实现负载均衡；⽀持Hadoop数据并⾏加载，对于像Hadoop的⼀样的⽇志数据和离线分析系统，但⼜要求实时处理的限制，这是⼀个可⾏的解决⽅案。
ZMQ-[总结]
![ZMQ-[总结]](https://img.taocdn.com/s3/m/27ee898ea0116c175f0e4832.png)
1ØMQ(ZeroMQ)简介zeromq是一个快速的通讯库。
轻量级的消息队列ZeroMQ（ØMQ/ZMQ）网络库的由来：“它提供一些跨多种传输协议（如进程内通讯、IPC、TCP和广播）的套接字供你使用。
你可使用多种方式实现N对N的套接字连接，譬如：扇出、发布订阅、任务分发以及请求响应。
”建立在socket 之上的light-weight message queue。
不再需要自己管理tcp 分包。
简单、实用。
来自iMatix 的一个库，iMatix 主要面向金融行业。
（业务逻辑决定设计）1.1 优点c++的消息中间件zeromq史上最强大的消息中间件，30us内完成消息传递，兼容多平台，多语言，很好熟悉消息队列技术如rabbitmq，zeromq高吞吐，低延时，超乎你的想象支持多语言，支持windowns，linux和各种平台它是个可伸缩层，分散在分布式系统间。
因此，它可支持任意大的应用程序。
ØMQ不是简单的点对点交互，相反，它定义了分布式系统的全局拓扑。
ØMQ应用程序没有锁，可并行运行。
此外，它可在多个线程、内核和主机盒之间弹性伸缩。
1.2 Zmq特点1)ZeroMQ交互是面向消息的。
它将人们每天为应用程序周而复始地进行的例行消息处理封装起来。
这意味着如果当客户端套接字发送一条150KB大小的消息时，服务端套接字无需显式处理任何缓存（buffer）或组帧，即能接接收到一条完整而相同的消息。
2)ZeroMQ套接字与传输协议无关：对于任何协议，只有单一且统一的发送消息和接收消息API。
缺省情况下支持进程内通讯、IPC、广播和TCP。
此外，协议间切换非常简单，仅需更改连接字符串的前缀即可。
3)ZeroMQ套接字能感知路由和网络拓扑。
因为我们不再需要显示地管理点对点的连接状态——在上面我们已经看到，所有这些都已经由ZeroMQ库封装好——所以单个ZeroMQ套接字可以绑定两个独立的端口并监听他们的入站请求消息；也可使用一个API调用向两个独立的套接字发送数据。
开发技术选型参考
开发技术选型参考监控平台：1、cat：CAT基于Java开发的实时应用监控平台，包括实时应用监控，业务监控https:///dianping/cat 点评网2、Open-Falcon：/ 小米(非java）人性化的互联网企业级监控系统* 数据采集免配置：agent自发现、支持Plugin、主动推送模式* 容量水平扩展：生产环境每秒50万次数据收集、告警、存储、绘图，可持续水平扩展。
* 告警策略自发现：Web界面、支持策略模板、模板继承和覆盖、多种告警方式、支持回调动作。
* 告警设置人性化：支持最大告警次数、告警级别设置、告警恢复通知、告警暂停、不同时段不同阈值、支持维护周期，支持告警合并。
* 历史数据高效查询：秒级返回上百个指标一年的历史数据。
* Dashboard人性化：多维度的数据展示，用户自定义Dashboard等功能。
* 架构设计高可用：整个系统无核心单点，易运维，易部署。
RPC框架1、pigeon : https:///dianping/pigeon点评网2、dubbo：http://dubbo.io/ 阿里3、dubbox：https:///dangdangdotcom/dubbox 当当网支持REST风格远程调用（HTTP + JSON/XML)支持基于Kryo和FST的Java高效序列化实现支持基于Jackson的JSON 序列化支持基于嵌入式Tomcat的HTTP remoting体系升级Spring升级ZooKeeper客户端支持完全基于Java代码的Dubbo配置调整Demo应用修正了dubbo的bug 包括配置、序列化、管理界面等等的bug4、motan: /weibocom/motan 新浪微博概述Motan 是一套高性能、易于使用的分布式远程服务调用(RPC)框架。
功能支持通过spring配置方式集成，无需额外编写代码即可为服务提供分布式调用能力。
支持集成consul、zookeeper等配置服务组件，提供集群环境的服务发现及治理能力。
zeromq的工作原理及使用
zeromq的工作原理及使用一、ZeroMQ使用1.1ZeroMQ概述ZeroMQ是一种基于消息队列的多线程网络库，其对套接字类型、连接处理、帧、甚至路由的底层细节进行抽象，提供跨越多种传输协议的套接字。
ZeroMQ是网络通信中新的一层，介于应用层和传输层之间（按照TCP/IP划分），其是一个可伸缩层，可并行运行，分散在分布式系统间。
ZeroMQ看起来想一个可嵌入的网络库，但其作用就像是一个并发框架。
它为你提供了各种传输工具，如进程内，进程间，TCP和组播中进行原子消息传递的套接字。
你可以使用各种模式实现N对N的套接字连接，这些模式包括发布订阅，请求应答，扇出模式，管道模式。
它的速度足够快，因此可以充当集群产品的结构，他的异步IO模型提供了可扩展的多核应用程序，用异步消息来处理任务。
它虽然是以C为源码进行开发，但是可以绑定多种语言。
1.2请求/应答模式说到“请求-应答”模式，不得不说的就是它的消息流动模型以及数据包装模型。
消息流动模型指的是该模式下，必须严格遵守“一问一答”的方式。
发出消息后，若没有收到回复，再发出第二条消息时就会抛出异常。
同样的，对于Rep也是，在没有接收到消息前，不允许发出消息。
基于此构成“一问一答”的响应模式。
1.2.1服务端import timeimport zmqcontext=zmq.Context()socket=context.socket(zmq.REP)socket.bind("tcp://*:5555")while True:#Wait for next request from clientmessage=socket.recv()print("Received request:%s"%message)#Do some'work'time.sleep(1)#Send reply back to clientsocket.send(b"World")1.2.2客户端import zmqcontext=zmq.Context()#Socket to talk to serverprint("Connecting to hello world server…")socket=context.socket(zmq.REQ)socket.connect("tcp://localhost:5555")#Do10requests,waiting each time for a responsefor request in range(10):print("Sending request%s…"%request)socket.send(b"Hello")#Get the reply.message=socket.recv()print("Received reply%s[%s]"%(request,message))1.3发布/订阅模式“发布-订阅”模式下，“发布者”绑定一个指定的地址，例如“192.168.55.210：5556”，“订阅者”连接到该地址。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
MQ介绍与选型MQ使用场景•异步通信有些业务不想也不需要立即处理消息。
消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。
想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
•解耦降低工程间的强依赖程度，针对异构系统进行适配。
在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。
通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
•冗余有些情况下，处理数据的过程会失败。
除非数据被持久化，否则将造成丢失。
消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。
许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
•扩展性因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。
不需要改变代码、不需要调节参数。
便于分布式扩容。
•过载保护在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。
使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
•可恢复性系统的一部分组件失效时，不会影响到整个系统。
消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
•顺序保证在大多使用场景下，数据处理的顺序都很重要。
大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。
•缓冲在任何重要的系统中，都会有需要不同的处理时间的元素。
消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度。
以调节系统响应时间。
•数据流处理分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择。
MQ原理MQ模型•Pub/Sub发布订阅（广播）：使用topic作为通信载体•PTP点对点:使用queue作为通信载体MQ组成•Broker：消息服务器，作为server提供消息核心服务•Producer:消息生产者，业务的发起方，负责生产消息传输给broker，•Consumer：消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理•Topic:主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的广播•Queue：队列，PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收•Message：消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输MQ常用协议•AMQP协议AMQP即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。
基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。
优点：可靠、通用•MQTT协议MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。
该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter 让房屋联网）的通信协议。
优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统•STOMP协议STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。
STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。
优点：命令模式（非topic\queue模式）•XMPP协议XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。
适用于服务器之间的准即时操作。
核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。
优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大•其他基于TCP/IP自定义的协议有些特殊框架（如：redis、kafka、zeroMq等）根据自身需要未严格遵循MQ规范，而是基于TCP\IP自行封装了一套协议，通过网络socket接口进行传输，实现了MQ 的功能。
MQ选型RabbitMQ使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。
同时实现了Broker 架构，核心思想是生产者不会将消息直接发送给队列，消息在发送给客户端时先在中心队列排队。
对路由(Routing)，负载均衡(Load balance)、数据持久化都有很好的支持。
多用于进行企业级的ESB整合。
ZeroMQ又称ØMQ、0MQ、ZMQ，号称最快的消息队列系统，专门为高吞吐量/低延迟的场景开发，在金融界的应用中经常使用，偏重于实时数据通信场景。
ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，开发成本高。
因此ZeroMQ 具有一个独特的非中间件的模式，更像一个socket library，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序本身就是使用ZeroMQ API完成逻辑服务的角色。
但是ZeroMQ仅提供非持久性的队列，如果down机，数据将会丢失。
如：Twitter的Storm中使用ZeroMQ作为数据流的传输。
ZeroMQ套接字是与传输层无关的：ZeroMQ套接字对所有传输层协议定义了统一的API 接口。
默认支持进程内(inproc)，进程间(IPC)，多播，TCP协议，在不同的协议之间切换只要简单的改变连接字符串的前缀。
可以在任何时候以最小的代价从进程间的本地通信切换到分布式下的TCP通信。
ZeroMQ在背后处理连接建立，断开和重连逻辑。
特性：•无锁的队列模型对于跨线程间的交互（用户端和session）之间的数据交换通道pipe，采用无锁的队列算法CAS；在pipe的两端注册有异步事件，在读或者写消息到pipe的时，会自动触发读写事件。
•批量处理的算法对于批量的消息，进行了适应性的优化，可以批量的接收和发送消息。
•多核下的线程绑定，无须CPU切换区别于传统的多线程并发模式，信号量或者临界区，zeroMQ充分利用多核的优势，每个核绑定运行一个工作者线程，避免多线程之间的CPU切换开销。
ActiveMQApache下的一个子项目。
使用Java完全支持JMS1.1和J2EE 1.4规范的JMS Provider 实现，少量代码就可以高效地实现高级应用场景。
可插拔的传输协议支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。
RabbitMQ、ZeroMQ、ActiveMQ 均支持常用的多种语言客户端C++、Java、.Net,、Python、Php、Ruby等。
Redis使用C语言开发的一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。
对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。
测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。
实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
KafkaApache下的一个子项目，使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统，具有以下特性：•快速持久化：通过磁盘顺序读写与零拷贝机制，可以在O(1)的系统开销下进行消息持久化；•高吞吐：在一台普通的服务器上既可以达到10W/s的吞吐速率；•高堆积：支持topic下消费者较长时间离线，消息堆积量大；•完全的分布式系统：Broker、Producer、Consumer都原生自动支持分布式，依赖zookeeper自动实现复杂均衡；•支持Hadoop数据并行加载：对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。
RocketMQ阿里系下开源的一款分布式、队列模型的消息中间件，原名Metaq，3.0 版本名称改为RocketMQ，是阿里参照kafka设计思想使用java实现的一套mq。
同时将阿里系内部多款mq产品（Notify、metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构，目前主要多用于订单交易系统。
具有以下特点：•能够保证严格的消息顺序•提供针对消息的过滤功能•提供丰富的消息拉取模式•高效的订阅者水平扩展能力•实时的消息订阅机制•亿级消息堆积能力官方提供了一些不同于kafka的对比差异：MQ对比配置使用方式性能对比Rabbitmq VS ZeroMq VS ActiveMq•20,000条msg\每条消息容量1024 bytes•200,000 条msg\每条消息容量32 bytes•200条msg\每条容量32768 bytesRabbitMq VS Redis•不同大小消息出队QPS对比RabbitMq VS Kafka使用场景建议参考：.org /results:ib-tests-v206。