MQ全称是Message Queue，是应用程序和应用程序之间的通信方法。在项目中，我们可以将不需要立即返回结果的操作提取出来，进行异步操作处理，以此提高系统吞吐量。
产生背景- 生产者-消费者模型：
- 生产者生成数据，数据存放内存中，消费者消费数据优点：存取速度快缺点：耗内存，不安全（服务端挂了，数据就丢失了），难以进行跨Java进程进行服务，没有统一管理，代码编写困难
- 借助数据库进行数据存储，生产者生产数据放在数据库中，消费者消费数据库数据优点：安全，可跨进程跨平台服务缺点：存取速度慢，数据存放于磁盘中
- 消息中间件是一个独立的进程服务，底层使用队列的模式，生产者将消息存放于队列中，消费者消费队列中的数据优点：数据存放在内存中，存取速度快，易进行跨Java进程进行服务，消息可以一对一或一对多进行消费，消费完成后会自动清除，安全性高（具有消息持久化和重试机制）缺点：耗内存
- JMS（全称：Java Message Service）是Java的消息服务标准，通过JMS标准，客户端可以和服务端进行异步的消息传输
- 点对点模式也就是一对一模式（类似于打电话），消息只能被一次消费，一旦被消费则会从消息队列中移除发送者发送消息到特定队列中，接收者从队列获取消息，队列会保存消息直到被消费或过期接收者接收到信息后，需向队列反馈对接收者没有要求，队列只做消息暂存
- 发布订阅模式是订阅者先订阅主题，发布者对主题发送消息后，订阅者会自动获取到消息一个主题可以有个多个发布者和多个订阅者具有较为时间相关性，订阅者必须先对主题进行订阅，然后一直运行，直到有发布者发布主题信息，为了缓和订阅者如此严格时间相关性，JMS允许订阅者创建可持久化的订阅，即使订阅者不在运行态，仍可以接收发布者消息订阅者对消息的消费可以是同步的，也可以是异步的
- 同步：订阅者调用reveice方法接收消息，在接收之前会一直处于阻塞状态（类似于BIO）异步：订阅者注册消息监听器，当消息到达后，会自动调用监听器的onMessage方法（类似于回调）
- RabbitMQ是使用Erlang编写的开源消息队列。本身支持很多协议，包括AMQP，XMPP，SMTP，STOMP。是一种重量级的消息队列，适合于企业级开发。实现了Broker架构（代理模式），消息在发送给客户端之前会先进入中心队列排队因为所有的消息都会经过中心队列，因此RabbitMQ对路由控制（Routing），负载均衡（Load Balance）以及数据持久化具有很好的支持
- Redis是一个key-value的NOSQL数据库，但其本身也支持MQ的功能，可将其当作一个轻量级队列服务使用在数据入列时，数据量较小时，Redis的性能要高于RabbitMQ，而当数据量超过10k，Redis的性能会急剧下降在数据出列时，无论数据量大小，Redis都有一个比较好的性能，RabbitMQ的出列性能要远低于Redis
- ZeroMQ号称是最快的消息队列系统，尤其针对于大吞吐量的需要场景能够实现RabbitMQ不擅长的高级/复杂队列需要开发人员自己组合多种技术框架，具有较高的技术复杂度ZeroMQ具有一个独特的非中间件模式，我们不需要安装和运行一个消息服务器，而只需要引用ZeroMQ的程序API（可以使用NuGET安装）然后就可以进行程序间的消息传递ZeroMQ是非持久化队列，市场上Twitter的Storm使用的就是ZeroMQ作为数据流的传输。
- ActiveMQ是Apache的一个子项目类似于ZeroMQ，可以代理人和点对点的技术实现队列同时类似于RabbitMQ，以少量的代码就能高效的实现高级的应用场景和RabbitMQ以及ZeroMQ一样，支持多种语言客户端，包括C++、JAVA、Python等
- Kafka是Apache的一个子项目，而Jafka是在Kafka之上孵化而来。Kafka是一个高性能、跨语言、分布式的发布订阅模式的消息队列具有快速持续化特性，可在时间复杂度O(1)的系统下进行消息持久化具有高吞吐量的特性，在一台普通的服务器上即可以达到10W/s的吞吐速率具有分布式的特性，其中Broker、Producer、Consumer都原生的自动支持分布式，能够自动实现复杂均衡支持类似于Hadoop的日志数据和离线分析且实时数据处理系统，通过Hadoop的并行加载机制统一处理在线和离线的消息是一个非常轻量级的消息中间件系统，性能较高且支持分布式
