消息中间件对比

图片.png

• RabbitMQ

是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。是AMQP协议领先的一个实现，它实现了代理(Broker)架构，意味着消息在 发送到客户端之前可以在中央节点上排队。对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。此特性使得RabbitMQ易于使用和部署，适宜于很多场景如路由、负载均衡或消息持久化等，用消息队列 只需几行代码即可搞定。但是，这使得它的可扩展性差，速度较慢，因为中央节点增加了延迟，消息封装后也比较大。如需配置RabbitMQ则需要在目标机器 上安装Erlang环境。

• ØMQ(ZeroMQ)

号称最快的消息队列系统，尤其针对大吞吐量的需求场景。是一个非常轻量级的消息系统， 专门为高吞吐量/低延迟的场景开发，在金融界的应用中经常可以发现它。与RabbitMQ相比，ZeroMQ支持许多高级消息场景，但是你必须实现 ZeroMQ框架中的各个块（比如Socket或Device等）。或则可以说ZeroMQ 是一套智能传输层协议
ØMQ(ZeroMQ)能够实现RabbitMQ不擅长的高级/复杂 的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装 和运行一个消息服务器或中间件，因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉 快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用 ZeroMQ作为数据流的传输。ZeroMQ非常灵活，但是你必须学习它的80页的手册（如果你要写一个分布式系统，一定要阅读它）。
ZeroMQ 没有中间件架构，不需要任何服务进程和运行。事实上，你的应用程序端点扮演了这个服务角色。这让部署起来非常简单，但担心的是，你没有地方可以观察它是否 有问题出现。就目前了解到的，ZeroMQ仅提供非持久性的队列。你可以在需要的地方实现自己的审计和数据恢复功能。

• MSMQ

这是微软的产品里唯一被认为有价值的东西。如果MSMQ能证明可以应对这种任务，他们将选择使用它。 关键是这个东西并不复杂，除了接收和发送，没有别的；它有一些硬性限制，比如最大消息体积是4MB。然而，通过和一些像MassTransit 或 NServiceBus这样的软件的连接，它完全可以解决这些问题。

• Jafka/Kafka

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

• Apache ActiveMQ

ActiveMQ居于两者(RabbitMQ & ZeroMQ)之间，类似于ZemoMQ，它可以部署于代理模式和P2P模式。类似于RabbitMQ，它易于实现高级场景，而且只需付出低消耗。
ActiveMQ被誉为Java世界的中坚力量。它有很长的历史，而且被广泛的使用。它还是跨平台的，给那些非微软平台的产品提供了一个天然的集成接入点。然而，它只有跑过了MSMQ才有可能被考虑。如需配置ActiveMQ则需要在目标机器上安装Java环境
需要注意一点的是ActiveMQ的下一代产品为Apollo，Apollo以ActiveMQ原型为基础，是一个更快、更可靠、更易于维护的消息代理工 具。Apache称Apollo为最快、最强健的STOMP（Streaming Text Orientated Message Protocol，流文本定向消息协议）服务器。
Apollo的特性如下：
支持Stomp 1.0和Stomp 1.1协议
主题和队列
队列浏览器
主题持久订阅
镜像队列
可靠的消息传递
消息过期和交换
消息选择器
JAAS验证
基于ACL的授权
支持SSL/TLS，证书验证
REST Management API

• Redis

是一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数 据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万 次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时 Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性 能，而RabbitMQ的出队性能则远低于Redis。

• MemcacheQ

持久化消息队列memcacheq(简称mcq)是一个轻量级的消息队列，MemcacheQ的特性：
1 简单易用
2 处理速度快
3 多条队列
4 并发性能好
5 与memcache的协议兼容。这就意味着只要装了memcache的extension就可以了，不需要额外的插件。
6 在zend framework中使用也很方便。

• Kestrel

Kestrel是twitter的开发团队用scala语言写的开源消息中间件，可以将消息持久存储到磁盘上，也可以将消息存储于内存中，但是不论保存磁盘还是内存中都可以设置消息存储的超期时间长短。
原先Kestrel是由Ruby写的Starling项目，但是后来 twitter的开发人员尝试用scala重新实现，并且可以支持Memcached的部分协议，例如：GET、SET、FLUSH_ALL、STATS。对于Kestrel 服务器端而言如果有N个
接收端连接在Kestrel服务器上，那么每个接收端会平均或者随机的收到不同的消息，并且发送端发过了消息接收端就算不接收，等到接收端再上去接收的时候还能收到消息，因为Kestrel支持消息持久化。
Kestrel 不存在主从 和 集群的概念，只存在分布式的说法，这有点类似memcached 通过客户端组成一个环状，对于Kestrel 服务器端而言，如果服务器端收到消息了，但是里面有消息没有收下来就挂了，再重启的时候接收端还能收到之前的消息。

• RocketMQ

一款分布式、队列模型的消息中间件，具有以下特点：

• 支持严格的消息顺序
• 支持Topic与Queue两种模式
• 亿级消息堆积能力
• 比较友好的分布式特性
• 同时支持Push与Pull方式消费消息