消息队列是啥？我认为大家都心知肚明，已经众所周知到不用解释的程度。只是。但凡学习、解释一样东西，都应该遵循
“它是什么？”、
“做什么用？”、
“为啥要用它”、
“它有啥分类”
这个套路。所以首先还是要给个定义。
世间无定义，老子仅仅好自己给个定义：消息队列嘛。首先是个队列，先进先出；然后，它传递消息。。。
一、消息队列的作用
有高手总结为：
1、异步处理
将不是必须的业务逻辑进行异步处理。换言之，就是能够马上返回。
比方说。注冊，注冊信息写入数据库以后。要发邮件，短信通知，假设等待这2样都完毕才返回，无论这2个步骤是串行还是并行，都要耗费时间。
引入消息队列以后。注冊信息写入数据库，随即写入消息队列，然后就能够返回了，兴许工作由消息队列进行处理。假如除了发通知，还添加其它操作。比方加积分什么的，这样的方式优势就更加明显。业务主体全然不必改动，仅仅需更改消息队列部分。
2、应用解耦
两个系统（或两个模块）之间本来直接调用，如今是通过消息队列间接调用，相似事件触发机制。这样就将两个系统或模块的关系由直接耦合变为松散耦合。
3、流量削峰
这个比較easy理解，引入排队机制。将并发变成了串行。
假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。
4、消息通讯
既然是消息队列嘛。怎么少得了发消息？
5、日志处理
我认为这应该属于 应用解耦 的范畴，为何单列出来？
下面以JMS讲述消息服务及使用。
JMS是java的消息服务。其API是一个消息服务的标准/规范。
二、消息模型
1、点对点（P2P）模式
P2P模式包括三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)。每一个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到他们被消费或超时。
P2P的特点：
1）每一个消息仅仅有一个消费者，一旦被消费，消息就不再在消息队列中。
2）发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后。无论接收者有没有正在执行。不会影响到消息被发送到队列。
3）接收者在成功接收消息之后需向队列应答成功 。
假设希望发送的每一个消息都会被成功处理的话，那么须要P2P模式。
2、生产者/消费者（Pub/Sub）模式
包括三个角色主题（Topic）。公布者（Publisher），订阅者（Subscriber） 多个公布者将消息发送到Topic,系统将这些消息传递给多个订阅者。
Pub/Sub的特点：
1）每一个消息能够有多个消费者
2）公布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后。才干消费公布者的消息
3）为了消费消息，订阅者必须保持执行的状态。或者创建一个可持久化的订阅。这样，即使订阅者没有被激活（执行），它也能接收到公布者的消息。
假设希望发送的消息能够不被做不论什么处理、或者仅仅被一个消息者处理、或者能够被多个消费者处理的话，那么能够採用Pub/Sub模型。
三、消息消费
对于消费来说。有两种方式：
1、同步
订阅者或接收者在接收到消息之前一直阻塞
2、异步
订阅者或接收者注冊一个消息监听器，消息到达后，读取消息。
四、经常使用消息队列
一般商用的容器，如WebLogic。JBoss，都支持JMS标准，能够直接使用消息队列。但免费的如Tomcat，Jetty等则须要使用第三方的消息中间件。
下面为一席经常使用的消息中间件：
1、ActiveMQ
Apache出品。号称最流行的，能力强劲的开源消息总线。
特点有兼容常见J2EEserver，支持Spring，Ajax
2、RabbitMQ
流行的、开源的消息队列。用AMQP（高级消息队列协议）标准实现。支持多种client。包括.Net，Java，PHP。
用于分布式系统中存储转发消息。易用性、扩展性、高可用性等方面表现不俗。
3、ZeroMQ
号称史上最快的消息队列，实际相似于Socket的一系列接口。普通Socket是端到端（1:1）的关系。而ZMQ是N:M。
ZMQ屏蔽了各种连接的细节，让网络编程更简单。
用于node与node间的通信。node能够是主机或进程。
4、Kafka
高吞吐量的分布式公布订阅消息系统。
持久化
高吞吐
集群、分区
支持Hadoop
參考资料：
关于消息队列的使用这里写链接内容