项目中要用到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：
