消息队列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的随笔

应用场景-异步处理　　　　

 应用场景-应用解耦

 应用场景-限流削峰

  应用场景-日志处理

 消息模式介绍-简介

一、点对点模式：REQ/REP

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

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

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

 三、推/拉模式：Push/Pull

　　也是一种比较重要的模式，不管是Push端仍是Pull端均可以作服务器，绑定到特定的地址等待对方访问。

　　若是咱们在Push端绑定地址，那么这是一个PushServer，对应的PullClient能够连接到这个PushServer往外拉数据；反之，若是创建一个PullServer，对应的PushClient就能够连接到PullServer并往里面压数据。

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

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

使用TurboMQ的注意事项：

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

二、减小无效的重复推送，高并发下能够利用Redis作一些去重处理。 

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