消息队列
消息队列是啥？我觉得大家都心知肚明，已经众所周知到不用解释的程度。不过，但凡学习、解释一样东西，都应该遵循
“它是什么？”、
“做什么用？”、
“为啥要用它”、
“它有啥分类”
这个套路，所以首先还是要给个定义。
世间无定义，老子只好自己给个定义：消息队列嘛，首先是个队列，先进先出；然后，它传递消息。。。
一、消息队列的作用
有高手总结为：
1、异步处理
将不是必须的业务逻辑进行异步处理，换言之，就是可以立即返回。
比如说，注册，注册信息写入数据库以后，要发邮件，短信通知，如果等待这2样都完成才返回，不管这2个步骤是串行还是并行，都要耗费时间。引入消息队列以后，注册信息写入数据库，随即写入消息队列，然后就可以返回了，后续工作由消息队列进行处理。假如除了发通知，还增加其他操作，比如加积分什么的，这种方式优势就更加明显，业务主体完全不必修改，只需更改消息队列部分。
2、应用解耦
两个系统（或两个模块）之间本来直接调用，现在是通过消息队列间接调用，类似事件触发机制，这样就将两个系统或模块的关系由直接耦合变为松散耦合。
3、流量削峰
这个比较容易理解，引入排队机制。将并发变成了串行。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。
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出品。号称最流行的，能力强劲的开源消息总线。
特点有兼容常见J2EE服务器，支持Spring，Ajax
2、RabbitMQ
流行的、开源的消息队列。用AMQP（高级消息队列协议）标准实现。支持多种客户端，包括.Net，Java，PHP。
用于分布式系统中存储转发消息。易用性、扩展性、高可用性等方面表现不俗。
3、ZeroMQ
号称史上最快的消息队列，实际类似于Socket的一系列接口。普通Socket是端到端（1:1）的关系，而ZMQ是N:M。ZMQ屏蔽了各种连接的细节，让网络编程更简单。
用于node与node间的通信。node可以是主机或进程。
4、Kafka
高吞吐量的分布式发布订阅消息系统。
持久化
高吞吐
集群、分区
支持Hadoop
蔚落
「爱情、让人受尽委屈。」
Bertha 。
红太狼
还没有评论，来说两句吧...