各大主流消息中间件有哪些区别

本篇内容主要讲解“各大主流消息中间件有哪些区别”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“各大主流消息中间件有哪些区别”吧!

创新互联公司网站建设公司，提供成都网站制作、成都做网站，网页设计，建网站，PHP网站建设等专业做网站服务;可快速的进行网站开发网页制作和功能扩展；专业做搜索引擎喜爱的网站，是专业的做网站团队，希望更多企业前来合作!

目录  

前言

1. 主流消息中间件介绍——ActiveMQ    

1.1 特点      

1.2 架构模式      

1.3 小结      

2. 主流消息中间件介绍——Kafka    

2.1 特点      

2.2 架构模式      

2.3 小结      

3. 主流消息中间件介绍——RocketMQ    

3.1 特点      

3.2 架构模式      

3.3 小结      

4. 为什么选择RabbitMQ？

5. 主流消息中间件介绍——RabbitMQ    

5.1 特点      

6. 对比分析图      

前言

消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。当今市面上有很多主流的消息中间件，如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发RocketMQ等。今天主要来介绍了下几大主流消息中间件的区别与联系。

1. 主流消息中间件介绍——ActiveMQ

ActiveMQ是由Apache出品，ActiveMQ是一个完全支持JMS1.1和J2EE 1.4规范的JMS Provider实现。它非常快速，支持多种语言的客户端和协议，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能。

1.1 特点

• ActiveMQ是Apache出品，最流行的，能力强劲的开源消息总线，并且它是一个完全支持JMS规范的消息中间件

• 其丰富的API、多种集群构建模式使得他成为业界老牌消息中间件，在中小型企业中应用广泛!

• MQ衡量指标：服务性能、数据存储、集群架构。

ActiveMQ现在用的比较少，因为ActiveMQ相比其他的MQ的性能来说比较一般。现如今高并发、大数据的应用场景随处可见。如果这时候在MQ的选择上，那么ActiveMQ就显得力不从心了。

衡量一个MQ的指标，主要有三个方面：服务性能、数据存储、集群架构
服务性能：ActiveMQ的性能不是特别好，面对超大规模并发时候，总是会出现各种各样的小问题，比如阻塞，消息堆积过多，产生一些延迟等等一些问题。
数据存储：ActiveMQ默认采用KahaDB内存存储方式。也可以采用一些高性能的存储方式，比如：google的LevelDb 基于内c存的。如果是为了保证消息的可靠，也可以采用MySQL或者oracle数据库。
集群架构：ActiveMQ流行那么多年，与其他组件集成的Api也是十分完善的。如果不是特别大的并发场景下，ActiveMQ也是一个不错的选择。因为ActiveMQ的集群架构模式也是十分好。

1.2 架构模式

Masrer-Slave模式
主备模式，利用Zookeeper进行两个或多个节点的协调。其中的主节点是对外提供服务的，而另外的从节点启动着，但是不对外提供服务。当主节点挂掉，利用Zookeeper进行一个高可用的切换，将Salve节点切换成主节点，继续对外提供服务。

NetWork模式

本质是两组主备模式的集成，中间用NewWork网关，做一个连接配置，就可以实现分布式集群。

1.3 小结

优点：

• 跨平台(JAVA编写与平台无关，ActiveMQ几乎可以运行在任何的JVM上)

• 可以用JDBC：可以将数据持久化到数据库。虽然使用JDBC会降低ActiveMQ的性能，但是数据库一直都是开发人员最熟悉的存储介质

• 支持JMS规范：支持JMS规范提供的统一接口

• 支持自动重连和错误重试机制

• 有安全机制：支持基于shiro，jaas等多种安全配置机制，可以对Queue/Topic进行认证和授权

• 监控完善：拥有完善的监控，包括WebConsole，JMX，Shell命令行，Jolokia的RESTful API

• 界面友善：提供的WebConsole可以满足大部分情况，还有很多第三方的组件可以使用，比如hawtio

缺点：

• 社区活跃度不及RabbitMQ高

• 根据其他用户反馈，会出莫名其妙的问题，会丢失消息

• 目前重心放到activemq6.0产品Apollo，对5.x的维护较少

• 不适合用于上千个队列的应用场景

2. 主流消息中间件介绍——Kafka

Apache Kafka是一个分布式消息发布订阅系统。它最初由LinkedIn公司基于独特的设计实现为一个分布式的日志提交系统(a distributed commit log)，之后成为Apache项目的一部分。Kafka性能高效、可扩展良好并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。

2.1 特点

kafka是LinkedIn开源的分布式发布-定于消息系统，目前归属于Apache顶级项目。Kafka主要特点是给予Pull的模式来处理消费消息，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。这里可以看出kafka只关注吞吐量。因此，在使用kafka的时候，注意业务是否允许消息重复、丢失、错误等。如果允许的话，kafka是最合适的。因为它的性能是最高的。即使在廉价的服务器上，也能支持单机每秒100k条以上的数据量。所以说它的性能是非常好的。kafka仅仅使用内存进行存储，只要有足够的内存，就能够足够大的吞吐量。因为kafka并没有在磁盘上进行读写。

• 快速持久化：可以在O(1)的系统开销下进行消息持久化；

• 高吞吐：在一台普通的服务器上既可以达到10W/s的吞吐速率；

• 完全的分布式系统：Broker、Producer和Consumer都原生自动支持分布式，自动实现负载均衡；

• 支持同步和异步复制两种高可用机制；

• 支持数据批量发送和拉取；

• 零拷贝技术(zero-copy)：减少IO操作步骤，提高系统吞吐量；

• 数据迁移、扩容对用户透明；

• 无需停机即可扩展机器；

• 其他特性：丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力、定期删除机制

2.2 架构模式

kafka架构模式

主要依赖Zookeeper进行协调管理，每一个kafka可以进行副本复制，也就是数据同步。假如说：有一条数据落在第一个节点上，那么就会进行repilicate 复制，这样在运行中每个节点就有一份数据，一共就有三分数据。如果说其中一台宕机，也能从另外两个节点中获取数据。部署方案建议：跨机房部署。即使有一台机子宕机，在数据上也是没有问题的。如果在整个地点宕机了。那么我们的数据也就丢失了。这也是大公司需要考虑的异地灾备。当然kafka主要关注性能的，对于数据的可靠性关注并高。

2.3 小结

优点：

• 客户端语言丰富：支持Java、.Net、PHP、Ruby、Python、Go等多种语言；

• 高性能：单机写入TPS约在100万条/秒，消息大小10个字节；

• 提供完全分布式架构，并有replica机制，拥有较高的可用性和可靠性，理论上支持消息无限堆积；

• 支持批量操作；

• 消费者采用Pull方式获取消息。消息有序，通过控制能够保证所有消息被消费且仅被消费一次；

• 有优秀的第三方KafkaWeb管理界面Kafka-Manager；

• 在日志领域比较成熟，被多家公司和多个开源项目使用。

缺点：

• Kafka单机超过64个队列/分区时，Load时会发生明显的飙高现象。队列越多，负载越高，发送消息响应时间变长；

• 使用短轮询方式，实时性取决于轮询间隔时间；

• 消费失败不支持重试；

• 支持消息顺序，但是一台代理宕机后，就会产生消息乱序；

• 社区更新较慢。

3. 主流消息中间件介绍——RocketMQ

RocketMQ是阿里开源的消息中间件，目前也已经孵化为Apache顶级项目。用Java语言实现，在设计时参考了Kafka，并做出了自己的一些改进，消息可靠性上比Kafka更好。RocketMQ在阿里内部被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。

3.1 特点

核心的特点如下：

• 保证消息的顺序性，消息按顺序消费。

• 提供了丰富的拉取和处理模式。

• 高效的订阅者，也可以进行水平扩展。

• 承载上亿级别的消息堆积能力。

3.2 架构模式

RocketMQ集群架构模式
1.Master-Slave（主从）模式
2.双Master模式。
3.双主双从模式。
4.多主多从模式。
5.一主多从模式。
可选方案许多种可供选择。

等等，参考了许多开源的设方式。

集群拓扑

阿里觉得Zookeeper性能太低，自己搭建了NameServer，这个NameServer代码也十分精简，一共也就几百行代码。有兴趣可以去读源码。

3.3 小结

优点：

• 单机支持1万以上持久化队列；

• RocketMQ的所有消息都是持久化的，先写入系统PAGECACHE，然后刷盘，可以保证内存与磁盘都有一份数据，而访问时，直接从内存读取。

• 模型简单，接口易用（JMS的接口很多场合并不太实用）；

• 性能非常好，可以允许大量堆积消息在Broker中；

• 支持多种消费模式，包括集群消费、广播消费等；

• 各个环节分布式扩展设计，支持主从和高可用；

• 开发度较活跃，版本更新很快。

缺点：

• 支持的 客户端语言不多，目前是Java及C++，其中C++还不成熟

• 维护RocketMQ需要专业的团队

• 商业版收费，有许多功能是不对外提供的。

• 没有在MQ核心里实现JMS等接口

4. 为什么选择RabbitMQ？

1.ActiveMQ，性能不是很好，因此在高并发的场景下，直接被pass掉了。它的Api很完善，在中小型互联网公司可以去使用。
2.kafka，主要强调高性能，如果对业务需要可靠性消息的投递的时候。那么就不能够选择kafka了。但是如果做一些日志收集呢，kafka还是很好的。因为kafka的性能是十分好的。
3.RocketMQ，它的特点非常好。它高性能、满足可靠性、分布式事物、支持水平扩展、上亿级别的消息堆积、主从之间的切换等等。MQ的所有优点它基本都满足。但是它最大的缺点：商业版收费。因此它有许多功能是不对外提供的。

那么说完这三种MQ还有没有其他MQ能够选择呢？有的，也是这次学习的MQ——RabbitMQ。

5. 主流消息中间件介绍——RabbitMQ

RabbitMQ于2007年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。

5.1 特点

RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。
AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。
AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。
RabbitMQ的可靠性是非常好的，数据能够保证百分之百的不丢失。可以使用镜像队列，它的稳定性非常好。所以说在我们互联网的金融行业。对数据的稳定性和可靠性要求都非常高的情况下，我们都会选择RabbitMQ。当然没有kafka性能好，但是要比AvtiveMQ性能要好很多。也可以自己做一些性能的优化。
RabbitMQ可以构建异地双活架构，包括每一个节点存储方式可以采用磁盘或者内存的方式。

RabbitMQ的集群架构

图中说的就是，我们可以采用三个节点作为RabbitMQ的一组集群，当然可以有许多组。节点与节点之间采用mirror queue。基于这种方式，能够保证数据百分之百的不丢失。
前端可以去做负载均衡，比如负载均衡组件：HA-proxy ，进行TCP级别的负载。
如果想做一个高可用的话，就需要借助keepAlived做一个高可用的配置。
比如前端加一个虚拟的VIP，通过VIP路由到指定的负载均衡组件，再有它路由到RabbtMQ的某一个节点。
这就是整个RabbitMQ集群架构。
能够实现非常完善，高可用并且性能也十分好，稳定性超强。并且有各种集群恢复手段。
比如:某一个节点挂了，或者某个磁盘损坏了，它也能进行一个消息修复。基于这么多优点，我们一定要把RabbitMQ学好。

6. 对比分析图

到此，相信大家对“各大主流消息中间件有哪些区别”有了更深的了解，不妨来实际操作一番吧！这里是创新互联网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！