java面试小结——MQ

ActiveMQ and RabbitMQ

　　　　ActiveMQ 和 RabbitMQ 都是AMQP 的一种具体实现。他们扮演着一个保证小心能够正常交付的角色。AcitveMQ 和 RabbitMQ 都支持 持久性或非持久性的信息交付。默认情况下，消息会存储到磁盘中，可以保证消息队列重启时数据的一致，避免消息的丢失。它们还支持同步和异步发送消息，前者对延迟有实质性影响。为了保证交付，这些代理使用消息确认，这也导致巨大的延迟代价。

　　　　就可用性和容错性而言，这些代理通过共享存储或无共享支持集群。队列可以跨集群节点进行复制，因此没有单点故障或消息丢失。

　　　　AMQP是一个非平凡的协议，其创作者声称过度设计。这些额外的保证是以牺牲主要复杂性和性能折衷为代价的。从根本上说，客户更难实现和使用。

　　　　由于它们是消息代理，ActiveMQ和RabbitMQ是需要在分布式系统中管理的额外移动部件，这会带来部署和维护成本。

RabbitMQ :结合erlang语言本身的并发优势，性能较好，但是不利于做二次开发和维护

ActiveMQ: 历史悠久的开源项目，已经在很多产品中得到应用，实现了JMS1.1规范，可以和spring-jms轻松融合，实现了多种协议，不够轻巧（源代码比RocketMQ多）.，支持持久化到数据库，对队列数较多的情况支持不好，不过我们的项目中并不会建很多的队列.

RabbitMQ：基于AMQP协议（Advanced Message Queue Protocol）
ActiveMQ：基于STOMP协议

网址：http://blog.csdn.net/lixiaoxiong55/article/details/45476789

在此之前，一直深信ActivetMQ做为老牌消息队列处理服务，能够胜任大部分的需求。不过最近第一次将它采用纳入项目中后，发现，它的队列，只支持简单的JSON格式文本，对于JSON嵌套类的格式文本，一旦消息提交到服务器后，消费端程序无法及时取到消息。服务器时不时产生拥堵，有时候几分钟，有时候十几分钟，消费端才会拿到数据。找了很多资料，也没有解，网上反映此类问题的不在少数。后来换成RabbitMQ，问题不再出现。消费端响应很及时，服务端也比较稳定。因此，建议初用消息队列，如果消息本身没有太多复杂程度，比如，只是几行简单字符串的话，ActiveMQ足以满需求。如果消息体需要承载大量文本信息，还带有各种特殊字符的话，不推荐ActiveMQ,使用RabbitMQ比较合适，而以后者的后台管理功能也比较完善。
网址：https://zhuanlan.zhihu.com/p/24366373