ActiveMQ和RabbitMQ的区别？
关于文章没多少内容，请进链接：https://blog.csdn.net/qq_30764991/article/details/80573352,
https://blog.csdn.net/qq_30764991/article/details/80516961好多学习内容，请自行学习。关于赞赏码倒是挺大的，哈哈，这个你得感谢中国伟大的企业家教育家马云先生(JACK MA),这个是自愿的，你自己从支付宝那里赚取，你看或者不看它就在那里，且行且珍惜短暂的人生路。加油！every body!everyone!everystudent!
1. ActiveMQ/ApolloMQ
优点：老牌的消息队列，使用Java语言编写。对JMS支持最好，采用多线程并发，资源消耗比较大。如果你的主语言是Java，可以重点考虑。
缺点：由于历史悠久，历史包袱较多，版本更新很缓慢。集群模式需要依赖Zookeeper实现。最新架构的产品被命名为Apollo，号称下一代ActiveMQ，目前案例较少。
2. RocketMQ/Kafka
优点：专为海量消息传递打造，主张使用拉模式，天然的集群、HA、负载均衡支持。话说还是那句话，适合不适合看你有没有那么大的量。
缺点：所谓鱼和熊掌不可兼得，放弃了一些消息中间件的灵活性，使用的场景较窄，需关注你的业务模式是否契合，否则山寨变相使用很别扭。除此之外，RocketMQ没有.NET下的客户端可用。RocketMQ身出名门，但使用者不多，生态较小，毕竟消息量能达到这种体量的公司不多，你也可以直接去购买阿里云的消息服务。Kafka生态完善，其代码是用Scala语言写成，可靠性比RocketMQ低一些。
3. RabbitMQ
优点：生态丰富，使用者众，有很多人在前面踩坑。AMQP协议的领导实现，支持多种场景。淘宝的MySQL集群内部有使用它进行通讯，OpenStack开源云平台的通信组件，最先在金融行业得到运用。
缺点：Erlang代码你Hold得住不? 虽然Erlang是天然集群化的，但RabbitMQ在高可用方面做起来还不是特别得心应手，别相信广告。
1.ActiveMQ/ApolloMQ
优点：老牌的消息队列，使用Java语言编写。对JMS支持最好，采用多线程并发，资源消耗比较大。如果你的主语言是Java，可以重点考虑。
缺点：由于历史悠久，历史包袱较多，版本更新很缓慢。集群模式需要依赖Zookeeper实现。最新架构的产品被命名为Apollo，号称下一代ActiveMQ，目前案例较少。
*ActiveMQ.
Java世界的中坚力量。它有很长的历史，而且被广泛的使用。它还是跨平台的，给那些非微软平台的产品提供了一个天然的集成接入点。然而，它只有跑过了MSMQ才有可能被考虑。
简介:
ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，尽管JMS规范出台已经是很久的事情了，但是JMS在当今的J2EE应用中间仍然扮演着特殊的地位。
拓展:
JMS:(http://baike.baidu.com/subview/157103/12665866.htm)
JMS即Java消息服务（Java Message Service）应用程序接口，是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。
特性列表:
⒈ 多种语言和协议编写客户端。语言: Java,C,C++,C#,Ruby,Perl,Python,PHP。应用协议： OpenWire,Stomp REST,WS Notification,XMPP,AMQP
⒉ 完全支持JMS1.1和J2EE 1.4规范 （持久化，XA消息，事务)
⒊ 对Spring的支持，ActiveMQ可以很容易内嵌到使用Spring的系统里面去，而且也支持Spring2.0的特性
⒋ 通过了常见J2EE服务器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的测试，其中通过JCA 1.5 resource adaptors的配置，可以让ActiveMQ可以自动的部署到任何兼容J2EE 1.4 商业服务器上
⒌ 支持多种传送协议：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
⒍ 支持通过JDBC和journal提供高速的消息持久化
⒎ 从设计上保证了高性能的集群，客户端-服务器，点对点
⒏ 支持Ajax
⒐ 支持与Axis的整合
⒑ 可以很容易得调用内嵌JMS provider，进行测试
2. RocketMQ/Kafka
优点：专为海量消息传递打造，主张使用拉模式，天然的集群、HA、负载均衡支持。话说还是那句话，适合不适合看你有没有那么大的量。
缺点：所谓鱼和熊掌不可兼得，放弃了一些消息中间件的灵活性，使用的场景较窄，需关注你的业务模式是否契合，否则山寨变相使用很别扭。除此之外，RocketMQ没有.NET下的客户端可用。RocketMQ身出名门，但使用者不多，生态较小，毕竟消息量能达到这种体量的公司不多，你也可以直接去购买阿里云的消息服务。Kafka生态完善，其代码是用Scala语言写成，可靠性比RocketMQ低一些。
3. RabbitMQ
优点：生态丰富，使用者众，有很多人在前面踩坑。AMQP协议的领导实现，支持多种场景。淘宝的MySQL集群内部有使用它进行通讯，OpenStack开源云平台的通信组件，最先在金融行业得到运用。
缺点：Erlang代码你Hold得住不? 虽然Erlang是天然集群化的，但RabbitMQ在高可用方面做起来还不是特别得心应手，别相信广告。
================================================================================================================
由于现在的数据处理量越来越大,对于消息队列的需求也越来越高,这里列举了市面上比较常见的几种消息队列,希望大家在以后的面试中能提供帮助.
MSMQ.
这是微软的产品里唯一被认为有价值的东西。这个东西并不复杂，除了接收和 发送，没有别的；它有一些硬性限制，比如最大消息体积是4MB。然而，通过和一些像MassTransit 或 NServiceBus这样的软件的连接，它完全可以解决这些问题。
简介:
MicroSoft Message Queuing（微软消息队列)是在多个不同的应用之间实现相互通信的一种异步传输模式，相互通信的应用可以分布于同一台机器上，也可以分布于相连的网络空间中的任一位置。它的实现原理是：消息的发送者把自己想要发送的信息放入一个容器中（我们称之为Message），然后把它保存至一个系统公用空间的消息队列(Message Queue)中；本地或者是异地的消息接收程序再从该队列中取出发给它的消息进行处理。
实质:
在消息传递机制中，有两个比较重要的概念。一个是消息，一个是队列。消息是由通信的双方所需要传递的信息，它可以是各式各样的媒体，如文本、声音、图象等等。消息最终的理解方式，为消息传递的双方事先商定，这样做的好处是，一是相当于对数据进行了简单的加密，二则采用自己定义的格式可以节省通信的传递量。消息可以含有发送和接收者的标识，这样只有指定的用户才能看到只传递给他的信息和返回是否操作成功的回执。消息也可以含有时间戳，以便于接收方对某些与时间相关的应用进行处理。消息还可以含有到期时间，它表明如果在指定时间内消息还未到达则作废，这主要应用与时间性关联较为紧密的应用。
消息队列是发送和接收消息的公用存储空间，它可以存在于内存中或者是物理文件中。消息可以以两种方式发送，即快递方式(express)和可恢复模式(recoverable)，它们的区别在于，快递方式为了消息的快速传递，把消息放置于内存中，而不放于物理磁盘上，以获取较高的处理能力；可恢复模式在传送过程的每一步骤中，都把消息写入物理磁盘中，以得到较好的故障恢复能力。消息队列可以放置在发送方、接收方所在的机器上，也可以单独放置在另外一台机器上。正是由于消息队列在放置方式上的灵活性，形成了消息传送机制的可靠性。当保存消息队列的机器发生故障而重新启动以后，以可恢复模式发送的消息可以恢复到故障发生之前的状态，而以快递方式发送的消息则丢失了。另一方面，采用消息传递机制，发送方不必要再担心接收方是否启动、是否发生故障等等非必要因素，只要消息成功发送出去，就可以认为处理完成，而实际上对方可能甚至未曾开机，或者实际完成交易时可能已经是第二天了。
作用:
采用MSMQ带来的好处是：由于是异步通信，无论是发送方还是接收方都不用等待对方返回成功消息，就可以执行余下的代码，因而大大地提高了事物处理的能力;当信息传送过程中，信息发送机制具有一定功能的故障恢复能力；MSMQ的消息传递机制使得消息通信的双方具有不同的物理平台成为可能。
在微软的.net平台上利用其提供的MSMQ功能，可以轻松创建或者删除消息队列、发送或者接收消息、甚至于对消息队列进行管理。
*ActiveMQ.
Java世界的中坚力量。它有很长的历史，而且被广泛的使用。它还是跨平台的，给那些非微软平台的产品提供了一个天然的集成接入点。然而，它只有跑过了MSMQ才有可能被考虑。
简介:
ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，尽管JMS规范出台已经是很久的事情了，但是JMS在当今的J2EE应用中间仍然扮演着特殊的地位。
拓展:
JMS:(http://baike.baidu.com/subview/157103/12665866.htm)
JMS即Java消息服务（Java Message Service）应用程序接口，是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。
特性列表:
⒈ 多种语言和协议编写客户端。语言: Java,C,C++,C#,Ruby,Perl,Python,PHP。应用协议： OpenWire,Stomp REST,WS Notification,XMPP,AMQP
⒉ 完全支持JMS1.1和J2EE 1.4规范 （持久化，XA消息，事务)
⒊ 对Spring的支持，ActiveMQ可以很容易内嵌到使用Spring的系统里面去，而且也支持Spring2.0的特性
⒋ 通过了常见J2EE服务器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的测试，其中通过JCA 1.5 resource adaptors的配置，可以让ActiveMQ可以自动的部署到任何兼容J2EE 1.4 商业服务器上
⒌ 支持多种传送协议：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
⒍ 支持通过JDBC和journal提供高速的消息持久化
⒎ 从设计上保证了高性能的集群，客户端-服务器，点对点
⒏ 支持Ajax
⒐ 支持与Axis的整合
⒑ 可以很容易得调用内嵌JMS provider，进行测试
RabbitMQ.
它支持开放的高级消息队列协议 (AMQP，Advanced Message Queuing Protocol)，从根本上避免了生产厂商的封闭，使用任何语言的各种客户都可以从中受益。这种协议提供了相当复杂的消息传输模式，所以基本上不需要 MassTransit 或 NServiceBus 的配合.
不多说,咱们都学过.
ZeroMQ.
开发这个产品的公司是AMQP集团的一部分，并且还有一个叫做OpenAMQ的产品。然而，他们却戏剧性的从AMQP分离的出去，并抱怨说这这个产品迷失了方向、变的越来越复杂。ZeroMQ具有一个独特的非中间件的模式，也就是说，跟其它几个接受测试的产品不同，你不需要安装和运行一个消息服务器，或 中间件。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。非常有趣的是，他们也同样使用这 方式在任何利用ZeroMQ进行强大的进程内通信的语言里创建Erlang风格的这种执行角色。
简介:
0MQ (ZeroMQ) 是一个轻量级消息内核。它可用于C、C++、Python、.NET /Mono、Fortran和Java语言。它运行在AIX ， FreeBSD的，基于HP - UX ， Linux和MacOS下， OpenBSD系统， OpenVMS ， QNX Neutrino， Solaris和Windows操作系统。
拓展:
博客园中有位大牛对于ZeroMQ做了详细的补充,有兴趣的同学可以自己去看看,下面提供了相应的地址:http://news.cnblogs.com/n/154000/
测试.
ActiveMQ需要 在目标机器上安装Java，RabbitMQ需要Erlang环境。安装这两个产品都没有遇到麻烦，但我想这是否给系统的维护增加了一层任务。如果这个中 的一个被选中，我需要让系统维护的人去理解和维护他们以前不熟悉的运行库。
ActiveMQ,RabbitMQ 和 MSMQ 都需要启动服务进程，这些都可以监控和配置，另外一个就有问题了。
ZeroMQ，它没有中间件架构，不需要任何服务进程和运行时。事实上，你的应用程序端点扮演了这个服务角色。这让部署起来非常简单，但担心的是， 你没有地方可以观察它是否有问题出现。就目前我知道的，ZeroMQ仅提供非持久性的队列。你可以在需要的地方实现自己的审计和数据恢复功能。老实说，我 甚至不确信是否该把它列在此次测试中，它的运行原理和其它几种差别太大了。
下面是测试结果。显示的是发送和接受的每秒钟的消息数。整个过程共产生1百万条1K的消息。测试的执行是在一个Windows Vista上进行的。
综合下来:
MSMQ的接收率是61.55%↓
ActiveMQ的接收率是100%↑
RabbitMQ的接收率是100%↑
ZeroMQ的接收率是36.55%↓
就像你看到的，ZeroMQ和其它的不是一个级别。它的性能惊人的高。公平的说，ZeroMQ跟其它几个比起来像头巨兽，尽管这样，结论很清楚：如果你希望一个应用程序发送消息越快越好，你选择ZeroMQ。当你不太在意偶然会丢失某些消息的情况下更有价值。
虽然说ZeroMQ的速度很惊人,但是对于数据就是生命的年代,我们宁可降低一些需求也不愿意丢失任何一条宝贵的数据,所以综合对比下来,我觉得RabbitMQ更适合.