mq介绍与选型

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即AdvancedMessageQueuingProtocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。优点：可靠、通用·MQTT协议MQTT（MessageQueuingTelemetryTransport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统·STOMP协议STOMP（StreamingTextOrientatedMessageProtocol）是流文本定向消息协议，是一种为MOM(MessageOrientedMiddleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。优点：命令模式（非topic\queue模式）·XMPP协议XMPP（可扩展消息处理现场协议，ExtensibleMessagingandPresenceProtocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大·其他基于TCP/IP自定义的协议有些特殊框架（如：redis、kafka、zeroMq等）根据自身需要未严格遵循MQ规范，而是基于TCP\IP自行封装了一套协议，通过网络socket接口进行传输，实现了MQ的功能。MQ选型RabbitMQ使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP,SMTP,STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了Broker架构，核心思想是生产者不会将消息直接发送给队列，消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Loadbalance)、数据持久化都有很好的支持。多用于进行企业级的ESB整合。ZeroMQ又称ØMQ、0MQ、ZMQ，号称最快的消息队列系统，专门为高吞吐量/低延迟的场景开发，在金融界的应用中经常使用，偏重于实时数据通信场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，开发成本高。因此ZeroMQ具有一个独特的非中间件的模式，更像一个socketlibrary，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序本身就是使用ZeroMQAPI完成逻辑服务的角色。但是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和J2EE1.4规范的JMSProvider实现，少量代码就可以高效地实现高级应用场景。可插拔的传输协议支持，比如：in-VM,TCP,SSL,NIO,UDP,multicast,JGroupsandJXTAtransports。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的对比差异：https://github.com/alibaba/RocketMQ/wiki/rmq_vs_kafkaMQ对比配置使用方式 MQ 语言 支持协议 持久化策略 消息确认机制 批处理 消息处理模式（push-pull） 消息顺序性 支持事务 集群策略 容灾 负载均衡 管理界面 RabbitMQ Erlang AMQPSTOMP(STOMP1.0,STOMP1.1andSTOMP1.2)MQTTHTTP(有三种方式)XMPP 本地磁盘文件 有消息确认机制 支持批量发送消息 push 　单个消费者有序 支持 主从模式支持自动选主 主从、镜像队列 　Rabbitmq-cluster或LVS或HAproxy rabbitmqadmin ActiveMQ Java AMQPMQTTOpenWireSTOMP AMQ(磁盘文件)、KahaDB(本地数据库)、JDBC、LevelDB(本地数据库) AUTO_ACKNOWLEDGE=1   自动确认CLIENT_ACKNOWLEDGE=2   客户端手动确认  DUPS_OK_ACKNOWLEDGE=3   自动批量确认SESSION_TRANSACTED=0   事务提交并确认自定义的ACK_MODE:INDIVIDUAL_ACKNOWLEDGE=4   单条消息确认 　支持批量发送消息 同时支持Push-pull 　单个消费者有序 支持 1、消费者集群2、Broker集群(共享队列)3、主从模式（共享DB、KahaDB复制、共享文件系统） 共享存储ZooKeeper协调 Broker-Cluster(共享队列)  ActiveMQWebConsole ZeroMQ C/C++ zmq_ipc(本地进程间通信)基于Socket的通信协议：TCP、INROC、IPC、PGM  不支持持久化 无，更像NIO模式下的非阻塞事件模式 支持 请求响应模式（同步）发布订阅模式（异步）单向管道模型 无 无 无 无 无 Redis C 自定义redis协议 支持磁盘持久化 无 支持 非严格意义push-pull 有序 支持 主从 主从或codis LVS或codis Redis-cli或redisLive Kafka scala 自定义 磁盘持久化 有消息确认机制 支持 Pull Topic单个partition内有序 否 zookeeper分布式多节点 分区副本 通过zookeeper调度topic分区 kafka-run-class.shKafka-managerKafka-offset-monitor性能对比RabbitmqVSZeroMqVSActiveMq·20,000条msg\每条消息容量1024bytes·200,000条msg\每条消息容量32bytes·200条msg\每条容量32768bytesRabbitMqVSRedis·不同大小消息出队QPS对比RabbitMqVSKafka使用场景建议 MQ TPS量级(持久化) 场景 备注 Rabbitmq 3500-4000msg/s 非海量高可靠性场景大规模企业应用、ESB复杂路由策略异构系统整合 协议丰富兼容性强，功能完善，消息格式比较大，速度较慢，消息持久化对性能影响明显 ZeroMq >800000msg/s 高并发连接场景，如：在线游戏海量高实时性场景，如：股票行情 偏重于网络开发，开发成本高，高级功能需自行实现，不建议做传统MQ应用 ActiveMq ~3600msg/s 非海量高可靠场景企业级应用分布式事务（XA）异构系统整合 相对Rabbitmq较轻量级，性能相近，完整JMS支持、配置较复杂 Redis ~15000msg/s 高吞吐低延迟大量小消息体（<10K）顺序性或排序要求异构系统整合 轻量级MQ的快速简单实现，容灾与负载等功能需自行完善 Kafka Input~70000msg/sOutput>150000msg/s 日志等海量数据流DB数据同步高堆积离线消息处理 非典型MQ，更偏重于流式数据批处理云服务商MQ对比UcloudMQ--UKafkahttps://docs.ucloud.cn/upd-docs/ukafka/index.html基于kafka实现的mq，兼容多版本功能：集群创建（最少3节点）、可选相应节点机型与数量，目前拥有三类共14种可选机型，调整参数、动态增删节点。特性：1.UKafka仅支持北京BPG-C、D，广州BPG数据中心，如在上述数据中心未查看到该标签，需申请开通2.可调整的配置参数有限，可配置的参数列表：3.目前未对ukafka单独绑定外网IP,故当前只能使用Ucloud提供的路由转发方式获取外网访问权限（unetwork）4.开发时监控和管理方式也是通过kafka-manager5.扩缩容与动态迁移：（1）UKafka集群至少拥有三个节点，并且默认的三个节点不可删除（2）不支持为线下节点做数据迁移，删除节点时需自行确认所删除节点中数据已留有备份（3）支持横向扩容，未提供纵向扩容的说明，具体是否有实现细节不明6.无kafka系统级监控，监控项未提供7.未提供kafka依赖的zk环境的配置与管理信息，细节不明对比：基本功能目前我方都以涵盖，细节监控与管理不如我方做的细致青云MQ--kafkahttps://docs.qingcloud.com/guide/queue.html基于kafka实现，功能同上，支持对集群进行分组配置特性：1.网络：（1）为了保障数据安全，青云-Kafka服务需要运行在受管的私有网络中，同时由于Kafka依赖于ZooKeeper，所以在创建一个Kafka服务之前，至少需要拥有一个路由器和一个受管私有网络以及在该网络中创建一个ZooKeeper集群，受管私有网络需要和路由器连接，并开启DHCP服务（默认开启）。青云提供了zk的服务，zk可以和broker不在同一私有网段（2）跨网访问：需使用青云提供的网络配置策略，配置集群节点的advertised为路由器转发的源地址和源端口2.添加节点时，支持手动或自动Ip分配，删除节点时需手动使用命令行做数据迁移3.同时支持横纵向扩容4.提供参数配置修改功能，但配置修改后需重启服务提供的配置参数列表：5.监控告警：提供了系统监控与服务监控，服务监控的实现通过JMX方式，可对每个节点覆盖，同时提供告警功能，监控告警类别：对比：功能与我方类似，推断具体的实现细节也类似我方，云上的网络配置较复杂阿里云MQ--ONShttps://www.aliyun.com/product/ons/?spm=5176.7946988.237031.127.yeQLaT基于阿里内部mq系统MetaQ、Notify与阿里开源产品RocketMQ实现，开发规范需遵循其定义，不兼容其他mq产品，提供了集群创建管理、命令集、SDK\openAPI、运维管控、监控报警、定制化服务特性：1.多种协议与接入方式：TCP、http、mqtt、rest、SDK2.支持定时消息（延迟消息），消息有效期：最长定时（延时）40天3.支持事务消息：实现类似X/OpenXA的分布事务功能，达到事务最终一致性，保障业务可靠稳定4.大消息：目前默认最大消息为256K,支持最大4M消息（北京）5.重置消费进度：重新消费一段时间（3天）内的消息6.消息过滤7.轨迹跟踪8.支持消费者状态查询对比：与我方实现体系不同，偏重互联网MQ特性设计，具体可参阅RocketMQ功能参考：http://www.rabbitmq.com/blog/tag/performance/http://blog.x-aeon.com/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/https://softwaremill.com/mqperf/http://www.infoq.com/cn/news/2014/08/zeromq-not-first-choice/http://zeromq.org/results:ib-tests-v206http://www.kuntalganguly.com/2014/08/message-queue-comparision.html