市面上消息队列的对比（想到就写点，持续更新,7/15）

1、RabbitMQ（2006）

• 介绍

RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。

• 缺点

维护成本较高基于 erlang 语言开发，社区活跃度一般，小团队维护成本较高

2、Redis

• 简介

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

• 性能

对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。

• 总结

实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

3、ZeroMQ

• 介绍

ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演这个服务器角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列·，也就是说如果宕机，数据将会丢失。其中，Twitter的Storm 0.9.0以前的版本中默认使用ZeroMQ作为数据流的传输（Storm从0.9版本开始同时支持ZeroMQ和Netty作为传输模块）。

4、ActiveMQ（2003）

ActiveMQ是Apache下的一个子项目。 类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。ActiveMQ由Apache软件基金会基于Java语言开发的一个开源的消息代理。能够支持多个客户机或服务器。计算机集群等属性支持ActiveMQ来管理通信系统。

5、Kafka/Jafka（2010）

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

1）图释

2）使用公司

Spotify：音乐流媒体
Netflix：电影电视剧流媒体
Cisco:思科
高盛投行

6、pulsar（2012）

7、rocketMQ（2011）

8、综合比较

1）综合评价

• 1）TEST FRAMEWORK
  
• 2）THROUGHPUT RESULTS
  
• 3）summary
  Kafka is endowed with a higher throughput while RocketMQ distinguish itself for its superiority in latency performance.
  

总结

1）若需要吞吐量(kafka)

Kafka is the best choice for users who need to do large-scale
data collection and analysis. Its high throughput can support
the collection of streaming data, and it can be used as the data
source of many data analysis tools, such as Flink [23], Spark
[22], Storm [39]. In general, Kafka is suitable for web site
activity tracking, streaming data collection and monitoring,
log merging, etc, and play the role of data source of big data
processing frameworks. It is recommended that the number of
consumers in the consumer group be the same as the number
of partitions, and that the appropriate number of partitions
should be set at each Broker to maximize performance.

2）若需要低延迟(rocketMQ)

If the message queuing system is used to process online
business, which requires low latency for high quality of service, RocketMQ is preferred. Due to its high reliability and
low latency, RocketMQ can be used in order transactions,
recharge, messaging push, real-time analysis and many other
applications. RocketMQ can support large amounts of topics
and message accumulation so that it can also be used in
complex business scenarios.

3）需要更多定制功能，比如延迟队列，优先级队列（pulsar）

Users may need message queue to provide multiple functionalities to implement their application systems. In such a case, Pulsar is usually a good choice because it offers more
functions than other message queuing systems, such as delay queuing and priority queuing.

2）消息队列核心模型

（1）生产者

• 概念
  生产数据的服务，通常也称为数据的输入提供方，这里的数据通常指我们的业务数据，例如推荐场景中用户对内容的点击数据、内容曝光数据、电商中的订单数据等等

• 像broker消息队列推送消息的策略
  在生产者发送数据时，通常会存在负载均衡的一些策略，常见的有按key hash、轮询、随机等方式。其本质是一条数据，被消息队列封装后也被称为一条消息，该条消息只能发送到其消息队列集群内部的一个分区队列中。因此只需按照一定的策略从多个队列中选择一个队列即可。

（2）消息队列集群

• 概念
  消息队列集群是消息队列这种组件实现中的核心中的核心，它的主要功能是存储消息、过滤消息、分发消息。

• 用主题对消息分类
  此外绝大部分的消息队列也都支持对消息进行分类，分类的标签称为topic（主题），一个topic中存放的是同一类消息。

（3）消费者

• 概念
  最终消息队列存储的消息会被消费者消费使用，消费者也可以看做消息队列中数据的输出方

• 获取数据方式
  推送（push）数据、拉取（pull）数据。

• 消费者模型1:N:M
  消费者消费者模型其实是一个1:N:M的关系，一份数据被N个消费者组独立使用，每个消费者组中有M个消费者进行分摊消费。
  

3）推/拉模型区别

4）消息队列数据组织方式

• 一种是存储在非易失性存储中，例如磁盘这种介质；
  1）难点一
  方面在于如何在不降低访问效率的情况下，充分利用有限的内存空间来存储尽可能多的数据，这个过程中少不了对数据结构的选型、优化；
  2）另一方面
  在于如何保证数据尽可能少的丢失，我们可以看到针对此问题的解决方案通常是快照+广泛意义的wal文件来解决。此类典型的代表就是redis啦。

• 另一种是选择存储在易失性存储中，典型的就是内存
  1）难点一方面在于
  如何根据系统所要解决的特点场景进行合理的对磁盘布局。读多写少情况下采用b+树方式存储数据；写多读少情况下采用lsm tree这类方案处理。
  2）另一方面在于
  如何尽可能减少对磁盘的频繁访问，一些做法是采用mmap进行内存映射，提升读性能；还有一些则是采用缓存机制缓存频繁访问的数据。还有一些则是采用巧妙的数据结构布局，充分利用磁盘预读特性保证系统性能。