Message Queue Summary

消息队列综述

​ 消息队列(Message queue)是一种进程间通信同一进程的不同线程间的通信方式,软件的队列用来处理一系列的输入,通常是来自用户。消息队列提供了异步的通信协议,每一个队列中的纪录包含详细说明的数据,包含发生的时间,以及特定的输入参数,也就是说:消息的发送者和接收者不需要同时与消息队列交互。消息会保存在队列中,直到接收者取回它。

 

1. MQ中间件的基本概念

​ 消息队列中间件是分布式系统中重要的组件,主要解决应用耦合、异步消息、流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。

1.1 MQ的组成

  1. Broker:队列管理器是为应用程序提供消息传递服务的程序。使用消息队列的应用程序可以将消息放置到队列并可从队列中获取消息。队列管理器确保消息可以发送至正确的队列。
  2. Producer:消息生产者,业务的发起方,负责生产消息传输给Broker。
  3. Consumer:消息消费者,业务的处理方,负责从Broker获取消息并进行业务逻辑处理。
  4. Topic:主题,发布订阅模式下的消息统一汇集地,不同生产者向topic发送消息,由MQ服务器分发到不同的订阅者,实现消息的广播。
  5. Queue:队列,PTP(Point to Point)模式下,特定生产者向特定queue发送消息,消费者订阅特定的queue完成指定消息的接收。
  6. Message:在MQ中,我们把应用程序交由MQ传输的数据定义为消息,我们可以定义消息的内容并对消息进行广义的理解,比如:用户的各种类型的数据文件,某个应用向其它应用发出的处理请求等都可以作为消息。

1.2 MQ的模型

1. PTP点对点:使用queue作为通信载体

2. Pub/Sub发布订阅(广播):使用topic作为通信载体

1.3 MQ常用协议

  • AMQP协议

    AMQP(Advanced Message Queuing Protocol),一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息,并不受客户端/中间件不同产品、不同开发语言等条件的限制。

    优点:可靠、通用

  • MQTT协议

    MQTT(Message Queuing Telemetry Transport)是一个客户端服务端架构的发布/订阅模式的消息传输协议。它的设计思想是轻巧、开放、简单、规范,易于实现。这些特点使得它对很多场景来说都是很好的选择,特别是对于受限的环境如机器与机器的通信(M2M)以及物联网环境(IoT)。

    优点:格式简洁、开销小、发布/订阅消息模式,提供一对多的消息发布、

  • 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的功能。

2. MQ的使用场景

  • 异步通信有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制,允许用户把一个消息放入队列,但并不立即处理它。想向队列中放入多少消息就放多少,然后在需要的时候再去处理它们。
  • 解耦降低工程间的强依赖程度,针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求,是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层,两边的处理过程都要实现这一接口,当应用发生变化时,可以独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。
  • 冗余有些情况下,处理数据的过程会失败。除非数据被持久化,否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中,在把一个消息从队列中删除之前,需要你的处理系统明确的指出该消息已经被处理完毕,从而确保你的数据被安全的保存直到你使用完毕。
  • 扩展性因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的,只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。
  • 过载保护在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量无法提取预知;如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。
  • 可恢复性系统的一部分组件失效时,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。
  • 顺序保证在大多使用场景下,数据处理的顺序都很重要。大部分消息队列本来就是排序的,并且能保证数据会按照特定的顺序来处理。
  • 缓冲在任何重要的系统中,都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行,该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。
  • 数据流处理分布式系统产生的海量数据流,如:业务日志、监控数据、用户行为等,针对这些数据流进行实时或批量采集汇总,然后进行大数据分析是当前互联网的必备技术,通过消息队列完成此类数据收集是最好的选择。

3.MQ选型

3.1 RabbitMQ

​ 使用Erlang编写的一个开源的消息队列,本身支持很多的协议:AMQP,XMPP, SMTP, STOMP。也正是如此,使的它变的非常重量级,更适合于企业级的开发。同时实现了Broker架构,核心思想是生产者不会将消息直接发送给队列,消息在发送给客户端时先在中心队列排队。对路由(Routing),负载均衡(Load balance)、数据持久化都有很好的支持。多用于进行企业级的ESB整合。

3.2 ActiveMQ

​ Apache下的一个子项目。使用Java完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现,少量代码就可以高效地实现高级应用场景。可插拔的传输协议支持,比如:in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。

3.3 ZeroMQ

​ 又称ØMQ、0MQ、ZMQ,号称最快的消息队列系统,专门为高吞吐量/低延迟的场景开发,在金融界的应用中经常使用,偏重于实时数据通信场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列,但是开发人员需要自己组合多种技术框架,开发成本高。因此ZeroMQ具有一个独特的非中间件的模式,更像一个socket library,你不需要安装和运行一个消息服务器或中间件,因为你的应用程序本身就是使用ZeroMQ API完成逻辑服务的角色。但是ZeroMQ仅提供非持久性的队列,如果宕机,数据将会丢失。如:Twitter的Storm中使用ZeroMQ作为数据流的传输。

​ ZeroMQ套接字是与传输层无关的:ZeroMQ套接字对所有传输层协议定义了统一的API接口。默认支持 进程内(inproc),进程间(IPC) ,多播 ,TCP协议,在不同的协议之间切换只要简单的改变连接字符串的前缀。可以在任何时候以最小的代价从进程间的本地通信切换到分布式下的TCP通信。ZeroMQ在背后处理连接建立,断开和重连逻辑。

特性:

  • 无锁的队列模型对于跨线程间的交互(用户端和session)之间的数据交换通道pipe,采用无锁的队列算法CAS;在pipe的两端注册有异步事件,在读或者写消息到pipe的时,会自动触发读写事件。
  • 批量处理的算法对于批量的消息,进行了适应性的优化,可以批量的接收和发送消息。
  • 多核下的线程绑定,无须CPU切换区别于传统的多线程并发模式,信号量或者临界区, zeroMQ充分利用多核的优势,每个核绑定运行一个工作者线程,避免多线程之间的CPU切换开销。

​ RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 PHP、 Ruby等。

3.4 RocketMQ

​ 阿里系下开源的一款分布式、队列模型的消息中间件,原名Metaq,3.0 版本名称改为RocketMQ,是阿里参照Kafka设计思想使用Java实现的一套MQ。同时将阿里系内部多款MQ产品(Notify、Metaq)进行整合,只维护核心功能,去除了所有其他运行时依赖,保证核心功能最简化,在此基础上配合阿里上述其他开源产品实现不同场景下MQ的架构,目前主要多用于订单交易系统。

具有以下特点:

  • 能够保证严格的消息顺序
  • 提供针对消息的过滤功能
  • 提供丰富的消息拉取模式
  • 高效的订阅者水平扩展能力
  • 实时的消息订阅机制
  • 亿级消息堆积能力

3.5 Kafka

​ Apache下的一个子项目,使用Scala实现的一个高性能分布式Publish/Subscribe消息队列系统,具有以下特性:

  • 快速持久化:通过磁盘顺序读写与零拷贝机制,可以在O(1)的系统开销下进行消息持久化;
  • 高吞吐:在一台普通的服务器上既可以达到10W/s的吞吐速率;
  • 高堆积:支持topic下消费者较长时间离线,消息堆积量大;
  • 完全的分布式系统:Broker、Producer、Consumer都原生自动支持分布式,依赖zookeeper自动实现复杂均衡;
  • 支持Hadoop数据并行加载:对于像Hadoop的一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。

3.6 Redis

​ 使用C语言开发的一个Key-Value的NoSQL数据库,开发维护很活跃,虽然它是一个Key-Value数据库存储系统,但它本身支持MQ功能,所以完全可以当做一个轻量级的队列服务来使用。

​ 对于RabbitMQ和Redis的入队和出队操作,各执行100万次,每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明:入队时,当数据比较小时Redis的性能要高于RabbitMQ,而如果数据大小超过了10K,Redis则慢的无法忍受;出队时,无论数据大小,Redis都表现出非常好的性能,而RabbitMQ的出队性能则远低于Redis。

3.7 MQ对比

3.7.1 使用对比

MQ语言支持协议持久化策略消息确认机制批处理消息处理模式(push-pull)消息顺序性支持事务集群策略容灾负载均衡管理界面
RabbitMQErlangAMQP STOMP (STOMP 1.0, STOMP 1.1 and STOMP 1.2)MQTTHTTP(有三种方式)本地磁盘文件有消息确认机制支持批量发送消息push单个消费者有序支持主从模式支持自动选主主从、镜像队列Rabbitmq-cluster或LVS或HAproxyrabbitmqadmin
ActiveMQJavaAMQPMQTTOpenWireSTOMPAMQ(磁盘文件)、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(共享队列)ActiveMQ Web Console
ZeroMQC/C++zmq_ipc(本地进程间通信)基于Socket的通信协议:TCP、INROC 、IPC 、PGM不支持持久化无,更像NIO模式下的非阻塞事件模式支持请求响应模式(同步)发布订阅模式(异步)单向管道模型
RedisC自定义redis协议支持磁盘持久化支持非严格意义push-pull有序支持主从主从或codisLVS或codisRedis-cli或redisLive
Kafkascala自定义磁盘持久化有消息确认机制支持PullTopic单个partition内有序zookeeper分布式多节点分区副本通过zookeeper调度topic分区kafka-run-clas

3.7.2 使用场景建议

MQTPS量级(持久化)场景备注         
Rabbitmq3500-4000msg/s非海量高可靠性场景协议丰富兼容性强,功能完善,消息格式比较大,速度较慢,消息持久化对性能影响明显
ZeroMq>800000msg/s高并发连接场景,如:在线游戏偏重于网络开发,开发成本高,高级功能需自行实现,不建议做传统MQ应用
ActiveMq~3600msg/s非海量高可靠场景相对Rabbitmq较轻量级,性能相近,完整JMS支持、配置较复杂
Redis~15000msg/s高吞吐低延迟轻量级MQ的快速简单实现,容灾与负载等功能需自行完善
KafkaInput ~70000msg/s日志等海量数据流非典型MQ,更偏重于流式数据批处理

发表评论

电子邮件地址不会被公开。 必填项已用*标注