消息队列

消息队列不仅解决了服务内部由于业务流程的同步执行而造成的阻塞，并且可以实现业务解耦。

 

　　什么是消息队列

　　消息队列：顾名思义，首先是一个队列，存放消息的队列

　　队列，先进先出，队列的操作有入队和出队，

　　也就是你有一个程序在产生内容然后入队（生产者）
　　另一个程序读取内容，内容出队（消费者）

　　

　　消息队列，简称MQ（Message Queue），它其实就指消息中间件

　　

　　同步机制：当客户端调用远程方法时，客户端必须等到远程方法完成后，才能继续执行。即使远程方法不向客户端返回任何消息，客户端也要被阻塞直到服务完成。

　　异步消息：如果消息时异步发送的，客户端不需要等待服务处理消息，甚至不需要等待消息投递完成。

 

　　消息队列的使用场景

　　　　系统解耦

　　　　　　解决系统之间的强调用关系，去除阻塞调用，改为异步消息

　　　　流量削峰

　　　　　　我们做秒杀实现的时候，需要避免流量暴涨，打垮应用系统的风险。可以在应用前面加入消息队列。接着慢慢从消息队列中消费消息即可

　　　　异步处理

　　　　　　串行执行的任务，改为异步执行，提高处理速度

　　　　消息通讯

　　　　　　消息队列内置了高效的通信机制，可用于消息通讯。如实现点对点消息队列、聊天室等。

　　　　远程调用

　　　　　　基于MQ，实现远程调用框架 

　　　　 

 

　　消息队列有两种模型：

　　1、点对点消息模型

　　　　在点对点消息模型中，每个消息都有一个发送者和一个接收者，当消息代理得到消息时，它将消息放入一个队列中。当接收者请求队列中的下一条消息时，消息会从队列中取出，并投递给接收者。因为消息投递后会从队列中删除，这样就可以保证消息只能投递给一个接收者。

 

　　2、发布——订阅消息模型

　　　　在发布——订阅模型中，消息会发送给一个主题。与队列类似，多个接收者都可以监听一个主题。但是，与队列不同的是，消息不再是只投递给一个接收者，而是主题的所哟订阅者都会接收此消息的副本。

           

 

　　异步消息的优点：

　　虽然同步通信比较容易理解，建立起来也比较简单，但是采用同步通信机制访问远程服务的客户端存在几个限制，最主要的是：

　　　　1.同步通信意味着等待。当客户端调用远程服务的方法时，它必须等待远程方法结束后才能继续执行。如果客户端与远程服务频繁通信，或者远程服务响应很慢，就会对客户端应用的性能带来负面影响。

　　　　2.客户端通过接口与远程服务相耦合。如果服务的接口发生变化，此服务的所有客户端都需要做相应的改变。

　　　　3.客户端与远程服务的位置耦合。客户端必须配置服务的网络位置，这样它才直到如何与远程服务进行交互。如果网络拓扑进行调整，客户端也需要重新配置新的网络位置。

　　　　4.客户端与服务的可用性相耦合，如果远程服务不可用，客户端实际上也无法正常运行。

 

 

　　消息队列选型：

　　　　目前常用的有Kafka、RocketMQ、RabbitMQ

　　　　先可以对比下它们优缺点：

	Kafka	RocketMQ	RabbitMQ
单机吞吐量	17.3w/s	11.6w/s	2.6w/s（消息做持久化）
开发语言	Scala/Java	Java	Erlang
主要维护者	Apache	Alibaba	Mozilla/Spring
订阅形式	基于topic，按照topic进行正则匹配的发布订阅模式	基于topic/messageTag，按照消息类型、属性进行正则匹配的发布订阅模式	提供了4种：direct, topic ,Headers和fanout。fanout就是广播模式
持久化	支持大量堆积	支持大量堆积	支持少量堆积
顺序消息	支持	支持	不支持
集群方式	天然的Leader-Slave，无状态集群，每台服务器既是Master也是Slave	常用 多对’Master-Slave’ 模式，开源版本需手动切换Slave变成Master	支持简单集群，'复制’模式，对高级集群模式支持不好。
性能稳定性	较差	一般	好

　　　　　　　　

　　　　　　　　RabbitMQ是开源的，比较稳定的支持，活跃度也高，但是不是Java语言开发的。

　　　　　　　　很多公司用RocketMQ，比较成熟，是阿里出品的

　　　　　　　　如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的

 

 

END.