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、常用的变阻器有BC型滑线变阻器，用于电路的电流和电压调节、电子设备及仪表等电路的控制或调节等。
3、BL型励磁变阻器用于直流电机的励磁或调速。
4、BQ型起动变阻器用于直流电动机的起动。
5、BT型变阻器用于直流电动机的励磁或调速。
6、BP型频敏变阻器用于三相交流绕线式异步电动机的起动控制。
7、变阻器的主要技术参数和电阻器类似。
变阻器的图形符号如图1-27所示。
8、变阻器可以调节电阻大小的装置，接在电路中能调整电流的大小。
一般的变阻器用电阻较大的导线（电阻线）和可以改变接触点以调节电阻线有效长度的装置构成。
9、作用：9.1限制电流，保护电路；9.2改变电路中电压的分配。
10、滑动变阻器是电学中常用器件之一，它的工作原理是通过改变接入电路部分电阻线的长度来改变电阻的，从而逐渐改变电路中的电流大小。
11、滑动变阻器的电阻丝一般是熔点高，电阻大的镍铬合金，电阻杆一般是电阻小的金属，所以电阻丝越长，电阻越大，电阻杆越短，电阻越小。
12、电阻丝外面涂着绝缘层，绕在绝缘管上，它的两端连在A、B两个接线柱上。
13、滑片P通过金属杆和接线柱C相连，滑片移动到不同位置时，A、C两个接线柱间电阻丝的长度不一样，这样就可以改变接入电路中电阻的大小。
14、一般的变阻器用电阻较大的导线和可以改变接触点以调节电阻线有效长度的装置组成。
15、滑动变阻器构造：15.1接线柱；15.2滑片；15.3线圈；15.4金属杆；15.5瓷筒。
16、原理：金属杆电阻小，电流顺着划片从金属丝流过从而改变了电阻丝接入电路的长度，也改变了电阻的大小。
17、滑动变阻器的电阻丝绕在绝缘瓷筒上，大部分滑动变阻器电阻丝为镍铬合金丝，电阻丝外面涂有绝缘层。
烟雾报警器
1.概述1.1有关“禁烟”的相关措施/“禁烟”势在必行吸烟被认为是造成早逝的第一杀手。
世界卫生组织等机构提醒说,世界上每秒钟有一个人因吸烟引起的疾病而死亡。
2009年8月，公安部下文明确要求，严令全国公安机关非常时期采取非常手段，对消防违法行为实施“六个一律”,其中就明确规定“对在有火灾危险场所吸烟者，一律拘留5日”。
消防部门的排查重点集中在加气加油站、大型批发市场等易燃易爆场所，以及地下商场、歌城、网吧等公众聚集性场所。
同时，若市民在易燃易爆场所遇上吸烟者，可先用手机摄像取证，并上前劝阻。
若对方继续吸烟，甚至出言辱骂、动手打人，可打110或119报警，也可直接将其扭送派出所，执法部门将从重处罚。
自此，一场全国范围内“禁止公共场所吸烟”的整治风暴拉开帷幕。
这绝对不是耸人听闻，事实胜于雄辩。
河南郑州，2 名在豫泰大厦内吸烟者被处以5 日以下拘留；湖南，累计30多人因为在加油站等具有火灾、爆炸危险的场所内吸烟，而被依法治安拘留。
浙江湖州，在童装企业缝纫车间内抽烟的男子聂某近日被处以3天行政拘留，这是浙江首次对在危险场所吸烟者处以拘留。
北京宣布打造“健康北京人—全民健康促进十年行动规划”，规划2018 年前公共场所全面禁烟；此外，广西、山东、江西、浙江、河南、沈阳、广东、云南等众多省市纷纷采取各种针对“禁烟”的措施与活动。
其中，香港实行全面禁烟，违者将最高处以5000 港元罚款。
截止到目前，全国已有150多个城市颁布实施公共场所禁烟规定。
世界卫生组织《烟草控制框架公约》与《防止接触烟草烟雾准则》规定，自2011年1月起，应当在所有室内公共场所、室内工作场所、公共交通工具和其他可能的室外公共场所完全禁止吸烟。
而根据世界卫生组织对194 个国家的统计结果，到2009 年底，已有84 个国家和地区通过法律法规禁止在公共场所和工作场所吸烟，其中16个国家和地区的所有机构全面禁烟，其余68个国家和地区的医疗卫生机构等2类以上机构全面禁烟。
消息队列RabbitMQ业务场景应用及解决方案
消息队列RabbitMQ业务场景应⽤及解决⽅案⽬录0. 博客参考使⽤docker第⼀次安装rabbitmq所踩过的坑消费者消息确认的三种⽅式⼀⽂带你搞定RabbitMQ死信队列rabbitmq系列1. 背景需求说明：两个系统间需要数据互通，订单系统需要把⼀些订单信息、订单明细、回款、其他发送给B系统，但这些数据不是同时⽣成，还会有修改。
直到订单的的状态改变为"审核通过"，订单信息(所有的)才不会再继续推送。
两个系统是双向的，订单系统也会发送⼀些信息告诉B系统订单已完成/已取消，B系统也可以发送⼀些信息告诉订单系统订单已完成/已取消。
从⽽促使对⽅的业务逻辑发⽣相应的变化。
该篇⽂章假定为单向请求即订单系统向B系统发送数据2. 技术选型消息队列(rabbitMQ)优点：异步，解耦(两个系统间)缺点：需考虑在发送消息后每个节点出现异常报错的处理⽅法及消费者端发⽣异常报错的处理⽅法；此外还有消息堆积等问题设想：在订单、回款、明细的add和edit⽅法中等待数据库事务操作成功后，异步发送消息给B系统定时任务(xxl-job)优点：有管理界⾯，每个微服务经过配置后在管理界⾯配置定时任务即可，后续可以⽅便修改时间，⽽⽆需在硬编码或在配置⽂件进⾏修改缺点：⽆法获知数据什么时候发⽣了修改，只能定时从数据库凭状态判断，只要订单未完成/未取消就⼀直推送数据，同时还需要判断数据是新增/修改/删除设想：和消息队列结合使⽤，将消费者这边未消费或消费失败的消息告知⽣产者或订单系统，使⽤定时任务去推送socket长连接或短连接长连接：⼀有数据变化就进⾏推送，消费者消费后进⾏反馈，但⽐较消耗资源短连接：⼀有数据变化就进⾏推送，消费者消费后进⾏反馈，但如果消费者处理消息报错或处理时间过长，则⽣产者⽆法判断是否消费成功3. 消息队列的⼏个常见问题⽣产者消息是否发送到交换机使⽤confirm机制告知⽣产者(事务也可以，但会降低效率(未测试过))消息是否由交换机转发到队列使⽤return机制告知⽣产者消费者消费者是否接收到消息使⽤⼿动确认的⽅式ack/nack如果未接收到消息，是否重试？重试⼏次？时间间隔多久？如果重试失败该如何处理在application.properties/yml配置rabbitmq的retry参数如果保证消息的幂等性(即针对消息重复推送如何只消费⼀条消息)⽣产者发送消息是传⼀个messageId（UUID），消费者在消费时使⽤缓存redis存储，如果第⼆次传过来的还是这个，则跳过如果消费失败，如果把消息转⼊死信队列配置相应的死信交换机和死信队列，对于业务队列配置相应的参数，使得消息在被拒绝时跳转⾄死信交换机和死信队列，供死信消费者处理(获得消息后根据业务来处理，是⼊库还是推送给⽣产者等等) 4. 代码功能开发及测试⾸先，创建两个demo，分别叫做rabbit-producer和rabbit-consumer。
基于单片机的烟雾检测报警系统毕业设计
毕业设计基于单片机的烟雾检测报警系统毕业设计（论文）原创性声明和使用授权说明原创性声明本人郑重承诺：所呈交的毕业设计（论文），是我个人在指导教师的指导下进行的研究工作及取得的成果。
尽我所知，除文中特别加以标注和致谢的地方外，不包含其他人或组织已经发表或公布过的研究成果，也不包含我为获得及其它教育机构的学位或学历而使用过的材料。
对本研究提供过帮助和做出过贡献的个人或集体，均已在文中作了明确的说明并表示了谢意。
作者签名：日期：指导教师签名：日期：使用授权说明本人完全了解大学关于收集、保存、使用毕业设计（论文）的规定，即：按照学校要求提交毕业设计（论文）的印刷本和电子版本；学校有权保存毕业设计（论文）的印刷本和电子版，并提供目录检索与阅览服务；学校可以采用影印、缩印、数字化或其它复制手段保存论文；在不以赢利为目的前提下，学校可以公布论文的部分或全部内容。
作者签名：日期：学位论文原创性声明本人郑重声明：所呈交的论文是本人在导师的指导下独立进行研究所取得的研究成果。
除了文中特别加以标注引用的内容外，本论文不包含任何其他个人或集体已经发表或撰写的成果作品。
对本文的研究做出重要贡献的个人和集体，均已在文中以明确方式标明。
本人完全意识到本声明的法律后果由本人承担。
作者签名：日期：年月日学位论文版权使用授权书本学位论文作者完全了解学校有关保留、使用学位论文的规定，同意学校保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。
本人授权大学可以将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。
涉密论文按学校规定处理。
作者签名：日期：年月日导师签名：日期：年月日注意事项1.设计（论文）的内容包括：1）封面（按教务处制定的标准封面格式制作）2）原创性声明3）中文摘要（300字左右）、关键词4）外文摘要、关键词5）目次页（附件不统一编入）6）论文主体部分：引言（或绪论）、正文、结论7）参考文献8）致谢9）附录（对论文支持必要时）2.论文字数要求：理工类设计（论文）正文字数不少于1万字（不包括图纸、程序清单等），文科类论文正文字数不少于1.2万字。
基于单片机智能火灾报警系统的设计(毕业设计)
教学单位学生学号编号本科毕业设计题目基于单片机智能火灾报警系统的设计学生姓名专业名称电子电气工程学院2011级通信工程指导教师2015 年 5 月8 日基于单片机智能火灾报警系统的设计摘要：伴随着时代不断的进步，人们越来越多的使用电子类设备，无论是家庭还是工厂使用的电器都越来越多，随之而来的是因为电器的不当使用所引起的火灾也与日俱增，我们的国家每年因为所用电器造成的火灾而损失很多。
火灾不仅带来了物品财产上的损失，也带给了我们失去亲人的悲痛。
所以研制出一款针对于家庭、宿舍等小环境的火灾报警系统是非常重要的。
本次设计以传感器和单片机作为烟雾报警器设计的核心器件，配合其它器件即可实现烟雾和温度报警等功能。
设计中单片机选用STC89C52作为控制器件，传感器选用MQ-2型半导体可燃气体敏感元件烟雾传感器实现烟雾的检测。
论文主要针对火灾报警系统中的各个组成部分及功能进行了详细的介绍和说明，在文章第二部分有该篇论文的总体方案设计，可设置烟雾浓度和高温报警值，当烟雾传感器检测到火灾释放的烟雾时，信号由ADC0832进行处理模数转化再到单片机进行处理，当检测到浓度超标时，蜂鸣器会发出滴滴的报警声。
同时，此系统还可以检测温度，火灾发生往往环境温度会升高，当检测到温度超过设定的报警温度时候，蜂鸣器也将产生报警。
第三四部分有很详细的系统软硬件的分析与讲解，还附有系统的流程图和其主控电路及外围设备电路之间的接口连接方式，最后，对系统在电路调试中出现的问题进行了分析与总结。
关键字：单片机；传感器；烟雾报警器Design of fire alarm system for single chip computer Abstract: Along with the time progress, people more and more use of electronic equipment, whether it is family and factory use appliances are more and more, the attendant is caused by the improper use of electrical fire is also increasing, our country every year because the electricity is caused by the fire and lose a lot. Fire not only brought goods property losses, but also bring us the grief of losing loved ones. So developed a needle for families, dormitories and other small environment of the fire alarm system is very important.The design of the sensor and single-chip microcomputer as the core design of a smoke alarm devices, with other devices can realize the temperature and smoke alarm etc. function. Design of MCU choose STC89C52 as control devices and sensors use mq-2 semiconductor combustible gas sensitive element smoke sensor to achieve smoke detection. Paper for fire alarm system in each part and function of a detailed introduction and explanation, in the article the second part is the overall design of the thesis can be set up smoke concentration and high temperature alarm value, when the smoke sensor to detect fires release smoke, signal by ADC0832 were processing analog-to-digital conversion to single chip to carry on processing, when the detected exceeding, the buzzer will drop the issue alarm sound. At the same time, the system can detect the temperature, fires often environmental temperature will rise. When the detected temperature exceeds the set temperature alarm, buzzer will also generate an alarm. The third part has a very detailed analysis of the software and hardware of the system and explain the, is accompanied by the interface between the flow chart of the system and its main control circuit and peripheral circuit connection mode. Finally, the problems appeared in system debugging of circuit are analyzed and summarized.Key words: sensor ; MCU ; The smoke alarm目录一毕设正文 (1)1 绪论 (1)1.1 课题背景 (1)1.2 烟雾报警器的国内外现状 (1)1.3 烟雾报警器的发展趋势 (2)2 总体方案设计 (3)2.1 烟雾检测传感器选型 (3)2.2 烟雾传感器关于报警的介绍 (5)2.3 单片机选型 (5)2.3.1 STC89C52单片机简介 (5)2.3.2 单片机的引脚功能描述 (6)2.3.3 温度采集模块 (8)3 系统的硬件电路 (9)3.1 单片机最小系统 (9)3.2 单片机的时钟电路与复位电路设计 (9)3.3 烟雾检测AD采集电路 (10)3.4 显示模块 (11)3.5 声音报警电路 (11)3.6 按键控制电路 (12)3.7 电源模块 (12)3.8 温度传感器(DS18B20)电路 (13)3.8.1 DSl8B20简介 (13)3.8.2 18B20接口电路 (16)4 系统软件的设计及流程图 (17)5 电路调试中遇到的问题及总结 (18)参考文献 (19)谢辞 (20)二附录 (21)1 总体原理图设计 (22)2 部分程序源代码 (23)3 实物图 (34)4 开题报告 (35)5 结题报告 (36)6 答辩报告 (37)一毕设正文1 绪论1.1 课题背景随着科技的不断发展，人们现在对于电器的应用越来越多，无论是家用电器，还是工厂使用的电器都越来越多。
MQ选型——精选推荐
MQ选型特性ActiveMQ RabbitMQ RocketMQ Kafka单机吞吐量万级，吞吐量⽐RocketMQ和Kafka要低了⼀个数量级万级，吞吐量⽐RocketMQ和Kafka要低了⼀个数量级10万级，RocketMQ也是可以⽀撑⾼吞吐的⼀种MQ10万级别，这是kafka最⼤的优点，就是吞吐量⾼。
⼀般配合⼤数据类的系统来进⾏实时数据计算、⽇志采集等场景topic数量对吞吐量的影响topic可以达到⼏百，⼏千个的级别，吞吐量会有较⼩幅度的下降这是RocketMQ的⼀⼤优势，在同等机器下，可以⽀撑⼤量的topictopic从⼏⼗个到⼏百个的时候，吞吐量会⼤幅度下降所以在同等机器下，kafka尽量保证topic数量不要过多。
如果要⽀撑⼤规模topic，需要增加更多的机器资源时效性ms级微秒级，这是rabbitmq的⼀⼤特点，延迟是最低的ms级延迟在ms级以内可⽤性⾼，基于主从架构实现⾼可⽤性⾼，基于主从架构实现⾼可⽤性⾮常⾼，分布式架构⾮常⾼，kafka是分布式的，⼀个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可⽤消息可靠性有较低的概率丢失数据经过参数优化配置，可以做到0丢失经过参数优化配置，消息可以做到0丢失功能⽀持MQ领域的功能极其完备基于erlang开发，所以并发能⼒很强，性能极其好，延时很低MQ功能较为完善，还是分布式的，扩展性好功能较为简单，主要⽀持简单的MQ功能，在⼤数据领域的实时计算以及⽇志采集被⼤规模使⽤，是事实上的标准优劣势总结⾮常成熟，功能强⼤，在业内⼤量的公司以及项⽬中都有应⽤偶尔会有较低概率丢失消息⽽且现在社区以及国内应⽤都越来越少，官⽅社区现在对ActiveMQ5.x维护越来越少，⼏个⽉才发布⼀个版本⽽且确实主要是基于解耦和异步来⽤的，较少在⼤规模吞吐的场景中使⽤erlang语⾔开发，性能极其好，延时很低；吞吐量到万级，MQ功能⽐较完备⽽且开源提供的管理界⾯⾮常棒，⽤起来很好⽤社区相对⽐较活跃，⼏乎每个⽉都发布⼏个版本分在国内⼀些互联⽹公司近⼏年⽤rabbitmq也⽐较多⼀些但是问题也是显⽽易见的，RabbitMQ确实吞吐量会低⼀些，这是因为他做的实现机制⽐较重。
MQ介绍与选型
MQ介绍与选型MQ使用场景•异步通信有些业务不想也不需要立即处理消息。
消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。
想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
•解耦降低工程间的强依赖程度，针对异构系统进行适配。
在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。
通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
•冗余有些情况下，处理数据的过程会失败。
除非数据被持久化，否则将造成丢失。
消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。
许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
•扩展性因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。
不需要改变代码、不需要调节参数。
便于分布式扩容。
•过载保护在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。
使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
•可恢复性系统的一部分组件失效时，不会影响到整个系统。
消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
•顺序保证在大多使用场景下，数据处理的顺序都很重要。
大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。
•缓冲在任何重要的系统中，都会有需要不同的处理时间的元素。
消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度。
MQ-80起重机计算说明书解读
MQ-80t/16t门式起重机计算说明书编制：复核：审核：批准：中铁大桥局集团第七工程有限公司2007年1月目录目录 (2)1.起重天车 (5)1.1起升机构的设计计算 (5)1.1.1 卷扬机的选型计算 (5)1.1.2 钢丝绳选型计算 (6)1.1.3 滑轮组选择计算 (7)1.1.4 扁担梁的强度验算 (8)1.2 运行机构的设计计算 (9)1.2.1运行阻力的计算： (10)1.2.2电动机的选择 (10)1.2.3减速器的选择 (12)1.2.4联轴器的选型 (12)1.2.5车轮与钢轨的选型 (14)1.2.6钢丝绳与滑轮和卷筒夹角验算 (15)1.2.7限制器的选择 (16)2．电动葫芦及其轨道的选型 (16)2.1电动葫芦的选型 (16)2.2轨道的选型及验算 (17)2.2.1轨道的选型 (17)2.2.2 轨道的验算 (17)3．起重机走行机构的设计计算 (20)3.1运行阻力的计算 (20)3.1.1 起重机满载运行时的最大摩擦阻力Fm (20)3.1.2 坡道阻力Fp (21)3.1.3 风阻力Fw (21)3.2电动机的选择 (22)3.2.1电动机的静动功率 (22)3.2.2电动机初选 (22)3.2.3电动机验算 (23)3.3减速器的选择 (23)3.4制动器的选择 (24)3.5联轴器的选型 (25)3.6运行打滑验算 (25)3.7车轮与钢轨的选型 (27)3.7.1车轮的疲劳验算 (27)3.7.2车轮踏面接触强度计算 (28)3.8销轴验算（连接活动支座与走行车箱） (29)4起重机金属结构的设计计算 (30)4.1主梁的设计计算 (30)4.2起重机的主梁腹杆的校核 (33)4.3角焊缝强度校核 (35)4.4起重机的抗倾覆稳定性 (35)4.5起重机防风抗滑装置的选择 (38)5.其他计算 (39)5.1起重机的支腿校核 (39)5．2起重机的支腿弯曲应力校核 (40)5.3螺栓强度的校核 (41)1.起重天车1.1起升机构的设计计算起升机构由驱动装置、钢丝绳卷绕系统、取物装置和安全保护装置等组成。
业务规则引擎-选型标准、产品对比分析
业务规则引擎--选型标准、产品对比分析摘要：文章阐述业务规则引擎产品选型标准,罗列各种开源产品,且对各种产品特点展开详细分析.最后列举两个选型实例关键字：选型标准，业务规则引擎，JRules，QuickRules，Jess，Blaze Advisor,Drools1Java规则引擎选型标准业务规则引擎产品选型需考虑以下因素：（1）规则引擎对中文的支持。
（2）产品的历史和应用行业背景。
（3）规则引擎处理性能。
（4）规则引擎资源要求。
（5）规则引擎是否支持JSR94标准。
（6）规则引擎是否支持J2EE架构。
（7）规则引擎是否支持XML。
（8）规则语言的开放性和可扩展性。
（9）规则库的开放性和可扩展性。
（10）规则库的版本控制。
（11）规则库的存储灵活性。
（12）产品在开发中的灵活性。
（13）产品在开发中的灵活性。
（14）规则引擎对Web的支持。
（15）规则引擎在部署中的方便性和灵活性。
2Java规则引擎商业产品Java规则引擎商业产品主要有：3Java规则引擎开源项目开源项目的实现主要包括：Drools规则引擎应用Rete算法的改进形式Rete-II算法。
从内部机制上讲，它使用了和Forgy的算法相同的概念和方法，但是增加了可与面向对象语言无缝连接的节点类型。
Mandarax基于反向推理（归纳法）。
能够较容易地实现多个数据源的集成。
例如，数据库记录能方便地集成为事实集(facts sets)，reflection用来集成对象模型中的功能。
目前不支持JSR 94。
OFBiz Rule Engine支持归纳法(Backward chaining).最初代码基于Steven John Metsker的“Building Parsers in Java”，不支持JSR 94。
JLisa是用来构建业务规则的强大框架，它有着扩展了LISP优秀特色的优点，比Clips 还要强大.这些特色对于多范例软件的开发是至关重要的.支持JSR 94。
三个主流消息中间件区别
市场上的消息中间件：mom4jmom4j是一个完全实现JMS1.1规范的消息中间件并且向下兼容JMS1.0与1.02.它提供了自己的消息处理存储使它独立于关系数据与语言,所以它的客户端可以用任何语言开发.OpenJMSOpenJMS是一个开源的Java Message Service API 1.0.2 规范的实现,它包含有以下特性：*. 它既支持点到点（point-to-point）（PTP）模型和发布/订阅（Pub/Sub）模型。
*. 支持同步与异步消息发送*. JDBC持久性管理使用数据库表来存储消息*. 可视化管理界面。
*. Applet支持。
*. 能够与Jakarta Tomcat这样的Servlet容器结合。
*. 支持RMI, TCP, HTTP 与SSL协议。
*. 客户端验证*. 提供可靠消息传输、事务和消息过滤UberMQUberMQ完全实现了Java Message Service 规范。
UberMQ是因为现有的许多JMS提供商已经违背了分布式计算的核心原则：快速与简单而开发的。
Hermes JMS利用它提供的Swing UI可以很好的实现监控JMS providers。
ActiveMQActiveMQ是一个开放源码基于Apache 2.0 licenced 发布并实现了JMS 1.1。
它能够与Geronimo，轻量级容器和任Java应用程序无缝的给合。
SomnifugiSomnifugi使得工作在同一个java虚拟机中的线程能实现消息互发。
MantaRayMantaRay基于peer-2-peer 技术。
它具有以下特性:1.它既支持点对点(point-to-point)的域，又支持发布/订阅(publish/subscribe)类型的域。
2.并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递，一致性消息和具有持久性的订阅者支持。
3.消息过滤体制。
4.能与WebLogic and WebSphere 给合。
RabbitMQ面试题 22道
异步：A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。
最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。
用户通过浏览器发起请求。
如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms。
削峰：减少高峰时期对服务器压力。
4. 消息队列有什么缺点缺点有以下几个：1. 系统可用性降低本来系统运行好好的，现在你非要加入个消息队列进去，那消息队列挂了，你的系统不是呵呵了。
因此，系统可用性会降低；2. 系统复杂度提高加入了消息队列，要多考虑很多方面的问题，比如：一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。
因此，需要考虑的东西更多，复杂性增大。
3. 一致性问题A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。
所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，做好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了 10 倍。
但是关键时刻，用，还是得用的。
5. 你们公司生产环境用的是什么消息中间件？这个首先你可以说下你们公司选用的是什么消息中间件，比如用的是RabbitMQ，然后可以初步给一些你对不同MQ中间件技术的选型分析。
举个例子：比如说ActiveMQ是老牌的消息中间件，国内很多公司过去运用的还是非常广泛的，功能很强大。
但是问题在于没法确认ActiveMQ可以支撑互联网公司的高并发、高负载以及高吞吐的复杂场景，在国内互联网公司落地较少。
- 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。