消息队列：中间件对比----Kafka、ActiveMQ、RabbitMQ及RocketMQ

消息队列定义

“消息队列”是在消息的传输过程中保存消息的容器。

MQ的优势

1. 系统解耦：交互系统之间无直接调用的关系，只有消息传输，实现了系统之间的解耦
2. 异步化：提高系统响应速度，使用了消息队列，生产者一方，把消息往队列里一扔，就可以立马返回，响应用户了。无需等待处理结果。
3. 提高系统稳定性，当系统中出现“生产“和“消费“的速度或稳定性等因素不一致的时候，可能会导致服务端或客户端服务异常。通过消息队列解耦，可以让系统更健壮、稳定。

MQ的特点

先进先出：消息队列的顺序在入队的时候就确定了，一般时不需要人工干预的。而且，最重要的时，数据只有一条数据在使用中。这也是MQ被广泛使用的原因；
发布订阅：这是一种很高效的处理方式。如果不发生堵塞，基本可以看作时同步操作，这种处理方式能够非常有效地提升服务器的利用率，这样的应用场景十分广泛；
持久化：持久化保证MQ的使用不只是一个部分场景的辅助工具，而是能让MQ像数据库一样存储核心数据；
分布式：在如今大流量，大数据的使用场景下，只支持单体应用的服务器软件基本无法使用，支持分布式的部署，才能被广泛使用。MQ的定位就是一个高性能的中间件。

MQ选型对比

RabbtMQ

是使用ErLang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMP，SMTP，STOMP等，也正是如此，使得它变得非常重量级，更适合于企业级的开发。同时实现了一个经纪人架构，这意味着消息在发送给客户端时会现在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。其具体的特点包括：

• 可靠性
• 灵活的路由
• 支持消息集群
• 高可用性
• 支持多种协议
• 支持多语言客户端
• 提供管理界面
• 提供跟踪机制
• 提供插件机制
  总结：RabbitMQ的最大优势在于提供了比较灵活的消息路由政策、高可用性、可靠性以及丰富的插件、多种平台支持和完善的文档。不过，由于AMQP协议本身导致它的实现比较重量，从而使得与其他MQ（比如Kafka）对比其吞吐量处于下风。

Jafka/Kafka

Kafka是Apache下的一个子项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现复杂均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制来统一了在线和离线的消息处理，这一点也是本课题所研究系统所看重的。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。其主要特点如下:

• 同时为发布和订阅提供高吞吐量，
• 消息持久化
• 分布式
• 消费信息采用Pull模式（消息被处理的状态实在Consumer端维护的，而不是服务器端维护，Broker无状态，Consumer自己保存offset）
• 支持Online和Offline场景，同时支持离线数据处理和实时数据处理。

ActiveMQ

ActiveMQ是Apache出品的一款开源消息中间件，旨在为应用程序提供高效、可扩展、稳定、安全的企业级消息通信。ActiveMQ实现了JMS1.1并提供了很多附加的特性，比如JMX管理、主从管理、消息组通信、消息优先级、延迟接受消息、虚拟接收者、消息持久化、消息队列监控等。

RocketMQ

RocketMQ是阿里巴巴与2012年开园的分布式消息中间件。作为经历过多次阿里“双11”这种“超级工程”洗礼并有稳定出色表现的国产中间件，以其高性能、低延迟和高可靠性等特性近年来被越来越多的企业所用，其主要特点如下：

• 具有灵活的可扩展性。（RocketMQ天然支持集群，其核心四大组件（NameServer、Broker、Producer、Consumer）的每一个都可以在没有单点故障的情况下进行水平扩展。）
• 具有海量消息堆积能力。（RocketMQ采用零拷贝原理实现了超大量消息的堆积能力，据说单机已经可以支持亿级消息堆积，而且在堆积了这么多消息后仍然保持写入低延迟）
• 支持顺序消息。（顺序消息分为全局有序消息和局部有序消息，一般推荐使用局部有序消息，即生产者通过将某一类消息按顺序发送至同一个队列来实现）
• 支持多种消息过滤方式。（消息过滤分为在服务器端过滤和在消费端过滤。在服务端过滤时可以按照消息消费者的要求进行过滤，有点事减少了不必要的消息传输，缺点是增加了消息服务器的负担，实现相对复杂。消费端过滤则完全由具体应用自定义实现，这种方式更加灵活，缺点是很多无用的信息会被传输给消息消费者。）
• 支持事务消息
• 支持回溯消费