MQ笔记

消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据（消息）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如 远程过程调用 的技术。排队指的是应用程序通过队列来通信。

为什么需要MQ

1.异步处理请求,缓解系统的压力。

2.实现多语言通信

3.避免并发问题

4.系统间解耦,方便透明的扩展或缩减生产者和消费者系统

5.稳定可靠

RabbitMQ

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

Redis

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

	入队				出队
	128B	512B	1K	10K	128B	512B	1K	10K
Redis	16088	15961	17094	25	15955	20449	18098	9355
RabbitMQ	10627	9916	9370	2366	3219	3174	2982	1588

ZeroMQ

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

ActiveMQ

ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，尽管JMS规范出台已经是很久的事情了，但是JMS在当今的J2EE应用中间仍然扮演着特殊的地位。

MQ 与 webservice的区别

Webservice 和MQ(MessageQueue)都是解决跨平台通信的常用手段，两者有哪些区别呢？

个人认为最本质的区别在于 Webservice近乎实时通信，而MQ却通常是延时通信。 什么意思呢？ 因为webservice其实就是本地服务器程序调用远程服务器上的方法，属于两者之间的交互，请求的时候需要等被请求的服务器做出回应后，另一端才会有所动作，也就是说，如果你请求的service服务器关闭了，或者中断了，那么你这边肯定就得不到答复了，你的这次请求就算是打水漂丢失了。   而MQ 则相当于是多了一个中间件  我所发送的请求 都必须先传达给 这个消息队列组件，然后由这个消息队列组件再去到另一个服务器上去请求，有了响应之后再 返回给 当初的请求程序，因为MessageQueue组件会把消息持久化放在本地，所以哪怕突然死机了，请求消息也是不会丢失的。 比如我们有些复杂的生成报表的请求，生成一张报表可能会相当繁杂，要这么几分钟，那我们肯定不可能在那干等，这时候就使用MQ，按这个请求报表的需求传给MQ,等到接收程序处理完返回之后，我这边会收到通知，这样就比较好。 常见的MQ组件 包括MSMQ ,Apache ActiveMQ以及一些开源mq等。