消息队列MQ简介

　　项目中要用到RabbitMQ，领导让我先了解一下。在之前的公司中，用到过消息队列MQ，阿里的那款RocketMQ，当时公司也做了简单的技术分享，自己也看了一些博客。自己在有道云笔记上，做了一些整理，但后来也就搁在那了。现在有时间，就对MQ的一些简单的概念做下整理吧。

　　RabbitMQ的一些介绍，请参考https://www.jianshu.com/p/e55e971aebd8，里面对一些概念和使用的讲解还是非常详细的。

什么是消息队列-定义

　　我们来看下维基百科上面的定义：

　　是一种进程间通信或同一进程的不同线程间的通信方式，软件的软件的贮列用来处理一系列的输入，通常是来自用户。

　　消息队列提供了异步的通信协议，每一个贮列中的纪录包含详细说明的数据，包含发生的时间，输入设备的种类，以及特定的输入参数。

　　也就是说：消息的发送者和接收者不需要同时与消息队列交互。消息会保存在队列中，知道接收者取回它。

下面是架构图：

Producer：消息生产者，负责生产和发送消息到Broker；

Broker：消息处理中心，负责消息存储、确认、重试等；

Consumer：消息消费中心，负责从Broker中获取消息并处理。

消息队列-特性

　　异步性：将耗时的同步任务通过发送消息的方式进行异步处理，减少等待时间。

　　松耦合：不同系统、服务之间可以通过消息队列进行通信，不用关心彼此的实现细节，数据格式一致。

　　分布式：为了防止消息堵塞，可以对消费者集群进行横向扩展，避免单点故障，同样队列本身也可以。

　　可靠性：将接收到的消息落盘，就算服务器重启或者发生故障，恢复之后也能重新加载。

应用场景-简单描述

　　根据特性，应用场景可以简单描述为：

　　　　在处理高并发，而且不需要立即获取结果的时候。

　　常用的消息队列有：

　　　　RabbitMQ，RocketMQ，ActiveMQ，Kafka等。数据库Redis或者MySQL也可以实现消息队列模式。Redis实现消息队列模式可以参考之前的一篇介绍Redis的随笔

应用场景-异步处理　　　　

应用场景-应用解耦

应用场景-限流削峰

应用场景-日志处理

 消息模式介绍-简介

1、点对点模式：REQ/REP

　　最基本的模式，生产者发送一条消息，消费者去除并消费信息，给出响应后会从队列中删除该消息，所以不能重复发送，只能被一个消费者消费。

2、发布/订阅模式：Pub/Sub

　　非常常见也是非常有用的一种模式，将发布者与订阅者进行解耦。发布者只负责生产数据，而不需要关心谁是订阅者，有多少订阅者。类比于微信公众号。

3、推/拉模式：Push/Pull

　　也是一种比较重要的模式，无论是Push端还是Pull端都可以做服务器，绑定到特定的地址等待对方访问。

　　如果我们在Push端绑定地址，那么这是一个PushServer，对应的PullClient可以链接到这个PushServer往外拉数据；反之，如果建立一个PullServer，对应的PushClient就可以链接到PullServer并往里面压数据。

4、路由/代理模式：Router/Dealer

　　是一种典型的中间人模式，比较适用于多对多的网络当中，双方在互相不认识的情况下达成共识并交易。类比于：顾客--->超时<--供应商。

使用TurboMQ的注意事项：

1、避免多线程处理消息，减少异步请求，不要开多余的Task去处理消息

2、减少无效的重复推送，高并发下可以利用Redis做一些去重处理。

下图是市场上的一些消息队列MQ：