消息队列MQ

一、消息队列

        网络端的Http请求默认采用的是同步请求方式，客户端与服务器端是基于请求和响应模式进行通信的。也就意味着，客户端发起请求。必须要等待服务器端完成处理结果给客户端才能继续进行下一步操作，如果服务器发送网络延迟、宕机、卡顿那么客户端势必会受到影响。

        基于这个问题下，MQ应运而生。MessageQueue消息队列，是一个按照先进先出队列设计的容器，主要用于对系统中产生的消息进行存储和消费。使用消息队列主要为了通过异步处理提高系统性能和降低峰值、降低系统耦合度等目的。主流的消息队列有：ActiveMQ、RabbitMQ、Kafka、RocketMQ。

        消息队列的本质其实就是生产-消费模型。系统运行过程中，按照不同的应用场景，不断地产生消息并发送至消息队列；当需要使用消息时，则按照先进先出的方式取出队列中的消息，进而消费消息。

 二、消息中间件的应用场景

        1.异步处理

        实际应用：短信通知、终端状态推送、App推送、用户注册等。

        设想一下当前场景：用户完成注册后，要实现发送注册邮件及注册短信功能。

        （1）串行方式：

        

                客户端发起请求，注册信息写入数据库后，先实现发送注册邮件，再发送注册短信耗时150毫秒。

        （2）并行方式：

        

                客户端发起请求，注册信息写入数据库后，同时执行发送注册邮件和短信耗时100毫秒。

        （3）如果引入消息中间件，即为

        

                将想要发送的消息写入消息队列，再由消息队列异步读取消费消息，这个过程耗时55毫秒，几乎等同于注册信息写入数据库，极大的提高了系统吞吐量。

        2.流量控制

        我们经常可以见到的例子，在某些直播间或者节日活动去秒杀某类热销商品时，如果说请求超过了一定的上限很容易造成服务器瘫痪的情况，这就造成了一定成度的麻烦。利用消息队列可以有效的阻隔相应的请求从而减少服务器的压力。

        

        在通过网关服务将请求转发到后端服务时，通过消息队列隔离网关和后端服务，来达到流量控制和保护后端服务的目的。设置消息队列的最大限制数，在达到最大数量时网关不再生产消息到消息队列中，例如：秒杀活动下，商品数量为100即消息队列的上限，超过100时下一个用户请求直接返回秒杀失败。

        3.服务解耦

        微服务架构服务与服务之间的通信是面向接口编程，如果引入消息队列，消息存储于消息队列中，当前服务有需要则从MQ获取消息消费即可，不需要也可以不消费。

        

        4.发布订阅

        用户想要获取消息队列中的消息，必须先注册订阅该消息。

        

        5.高并发缓冲

        系统在某个时间点的访问量巨大，依然超出了后端接口的每秒最大处理能力，这就导致服务器过载，响应延迟甚至于服务器宕机。

        针对这样场景吗，可以利用消息队列将临时数据写入消息队列，由消息队列临时缓存至磁盘，降低高峰数据对后端的短暂冲击。

 三、常见消息中间件

常见消息队列

特性MQ	ActiveMQ	RabbitMQ	RocketMQ	Kafka
是否支持生产者消费模式	√	√	√	√
是否支持发布订阅模式	√	√	√	√
是否支持请求回应模式	√	√	×	×
Api完整性	高	高	高	高
是否支持多语言	√	√	Java	√
单机吞吐量	万级	万级	万级	十万级
消息延迟	无	微妙级	毫秒级	毫秒级
可用性	高（主从）	高（主从）	非常高（分布式）	非常高（分布式）
消息丢失	低	低	几乎不	几乎不
文档的完备性	高	高	较高	高
提供快速入门	√	√	√	√
社区活跃度	有	有	有	有
商业支持	×	×	商业云	商业云

        以上就是对消息队列的初步认识喽。