MQ(message queue)，字面意思是，本质是队列，FIFO 先进先出只不过队 列中存储的内容是message 只是，它仍然是一种跨过程通信机制，用于上下游传递信息。 在互联网架构中，MQ 逻辑解耦+是上下游非常常见的一种;物理解耦“消息通信服务” 务。使用了 MQ 之后，消息发送到上游只需要依赖 MQ，不依赖其他服务。
1、异步。
如： 用户注册发送注册邮件，注册短信。
传统做法 ：
(1)、串行 （先发邮件，再发短信）。问题：持续时间长。
(2)、并行（将注册信息写入数据库后，同时发送邮件和短信），速度快，但不能满足高 吞吐需求。
消息队列的做法 ：
将数据写入数据库，并发送邮件和注册信息c;异步处理。
2、应用解耦。
如：双十一购物节下单后，订单系统通知库存系统。
传统做法 :。
调用库存系统接口的订单系统。问题：库存接口故障订单会失败，而大量订单的损失。
消息队列的做法。
订单系统：下单，订单系统完成持久性，将信息写入队列，成功返回订单给用户 库存系统：订阅订单的消息，获取订单消息，仓库操作，即使库存系统故障消息队 还能保证信息的可靠投递，消息不会丢失。
3、流量削峰。
如：秒杀活动通常是因为流量太大，导致应用程序挂断消息队列通常添加到应用程序的前端。 功能： 1、可以控制活动人数，超过一定阈值直接丢弃订单 2、可缓解短时间高流量压缩应用（应用程序根据其最大处理能力获得订单）
(1). ActiveMQ。
优点：单机吞吐量万等级时效性 ms 等级，高可用性�实现基于主从架构的高可用性， 消息可靠性高，数据丢失的概率较低。
缺点: 现在官方社区是对的 ActiveMQ 5.x 维护越来越少很少使用高吞吐量场景。
(2). Kafka。
大数据的杀手锏，在大数据领域谈论消息传输，则绕不开 Kafka，这是大数据 新闻中间件， 以其百万级 TPS 吞吐量名声大噪，迅速成为大数据领域的宠儿 儿，在数据采集、传输和存储过程中发挥着重要作用。目前已经被 LinkedIn， Uber, Twitter, Netflix 等待大公司采纳。
优点: 卓越的性能单机写入 TPS 100万/秒左右的xff0c;最大的优势，吞吐量高。时 效性 ms 非常高级的可用性kafka 分布式，多个数据副本，少数机器停机，不 会丢失数据不会导致不可用，消费者使用 Pull 获取消息的方式， 消息有序, 可以通过控制 确保所有消息都被消费，只被消费一次； 优秀的第三方Kafka Web 管理界面 KafkaManager；日志领域比较成熟，#xff1被多家公司和多个开源项目使用b;功能支持： 功能较 为简单，主要支持简单 MQ 功能，大数据领域的实时计算和日志采集是大规模的 用 。
缺点：Kafka 单机超过 64 队列/分区，Load 会出现明显的飙升现象，队列越多，#xff0c; load 越高c;发送消息响应时间长，使用短轮询法，实时性取决于轮询间隔时间，消 失败不支持重试；支持消息顺序， 但是，代理机构停机后会有消息乱序，社区更 新慢；
(3). RocketMQ 。
RocketMQ 阿里巴巴的开源产品，用 Java 语言实现�参考设计 Kafka， 并做出了自己的改进。被阿里巴巴广泛应用于订单，交易，充值，流量计算，消息推 送，日志流式处理，binglog 分发等场景。
优点: 单机吞吐量10万级， 非常高的可用性，分布式架构， 新闻可以做到 0 丢失, MQ 功能相对完善，还是分布式，扩展性好, 支持 10 1亿级消息积累，不会因为积累而导 性能下降， 源码是 java 我们可以自己阅读源码定制自己的公司 MQ 。
缺点：支持的客户端语言不多，目前是 java 及 c++，其中 c++不成熟；社区活跃度 一般来说，MQ核心没有实现 JMS 等接口，有些系统需要修改大量的代码才能迁移。
(4). RabbitMQ 。
2007 年发布c;在AMQP(高级消息队列协议)的基础上完成的，可重复使用的企业新闻 系统，它是目前最主流的新闻中间件之一。
优点: 由于 erlang 语言的高并发特性，性能好；吞吐量为万级，MQ 功能比较完 准备、健壮、稳定、易用、跨平台、支持多种语言 如：Python、Ruby、.NET、Java、 JMS、C、PHP、ActionScript、XMPP、STOMP 等，支持 AJAX 文档齐全；开源提供 管理界面很棒，使用方便，社区活动度高；更新频率相当高 https://www.rabbitmq.com/news.html 。
缺点：商业版需要收费，学习成本高。
(1). Kafka Kafka。
主要特点是基于Pulll 处理消息消费的模式，追求高吞吐量目的的的开始 它用于收集和传输日志，数据收集业务适用于生成大量数据的互联网服务。大型公司 建议选择如果有日志采集功能， 肯定是首选 kafka 了。
(2). RocketMQ。
出生在金融互联网领域对可靠性要求高的场景，特别是电子商务中的订单扣除 款式，以及业务削峰，在大量交易涌入时，后端可能无法及时处理。RoketMQ 在 在稳定性方面，它可能更值得信赖这些业务场景在阿里巴巴双 11 已经经历了多次测试，如果你的 业务有上述并发场景，可以选择建议 RocketMQ。
(3). RabbitMQ。
结合 erlang 语言本身的并发优势，性能好，时效性好，微秒级，#xff0c;社区活动也相对较高管 理论界面使用非常方便，如果你的数据量不是那么大，中小企业优先选择功能比较 准备RabbitMQ。
RabbitMQ 新闻中间件：它接受并转发消息。你可以把它当作快递站点， 当你想发送一个包裹时，，你把你的包裹放在快递站，快递员最终会把你的快递送到收件人 那里的人，按照这个逻辑 RabbitMQ 快递站，快递员会帮你传递快件。 RabbitMQ 与快递站的主要区别在于，它不处理快件，而是接收#xff0c; 新闻数据的存储和转发。
(1)生产者。
数据发送消息的程序是生产者。
(2)交换机。
交换机是 RabbitMQ 一个非常重要的部件，一方面，它收到了生产者的消息，另一 它将消息推送到队列中。交换机必须知道如何处理它收到的信息，是将这些 将消息推送到特定队列或推送到多个队列，或者丢弃消息，这必须有交换机类型 决定。
(3)队列。
队列是 RabbitMQ 内部使用的数据结构，尽管消息流经 RabbitMQ 和应用程 序列，但它们只能存储在队列中。队列仅受主机内存和磁盘的限制的限制c;本质上是一个 大新闻缓冲区。许多制造商可以将消息发送到队列，许多消费者可以尝试从一个开始 队列接收数据。这就是我们使用队列的方式。
(4)消费者。
消费和接收有相似的含义。大多数时候，消费者是一个等待接收消息的程序。请注意生 产品，消费者和消息中间件往往不在同一台机器上。同一个应用程序可以生产 也可以是消费者。
Hello Wold 简单模式。
Work queues 工作队列模式。
Publish/Subscribe 发布订阅模式。
Routing 路由模式。
Topics 主题模式。
Publisher Confirms 发布确认模式。
Broker：应用程序接收和分发信息，RabbitMQ Server 就是 Message Broker。
Virtual host：是为多个租户和安全因素而设计的c;把 AMQP 将基本组件划分为虚拟组件 在拟议的分组中，类似于网络 namespace 概念。当多个不同的用户使用相同的用户时 RabbitMQ server #xff0提供服务时&#c;多个可以分开 vhost，每一个用户都属于自己 vhost 创建 exchange／queue 等。
Connection：publisher／consumer 和 broker 之间的 TCP 连接。
Channel：假如每一次访问 RabbitMQ 都建立一个 Connection，新闻量大的时候 建立 TCP Connection 费用将是巨大的，效率也较低。Channel 是在 connection 内部建立的逻辑连接，如果应用程序支持多线程，通常每个 thread 创 建单独的 channel 通信，AMQP method 包含了 channel id 帮助客户端和 message broker 识别 channel，所以 channel 两者完全隔离。Channel 作为轻 Conectionection 大大降低了操作系统的建立 TCP connection 的开销。
Exchange：message 到达 broker 第一站，根据分发规则匹配查询表中的 routing key，分发消息到 queue 中去。常用的类型有：direct (point-to-point), topic (publish-subscribe) and fanout (multicast)。
Queue：消息终于被送到这里等待 consumer 取走。
Binding：exchange 和queue 虚拟连接，binding 中可以包含 routing key， Binding 保存了信息 exchange 在查询表中，用于 message 分发依据。
延时队列，队列内部有序，最重要的特征体现在其延迟属性上，延迟队列中的元素是在指定时间到达后或之前取出和处理，简单来说，，延迟队列是用来存储需要在指定时间处理的元素的队列。
(1). 如果订单在十分钟内未付款，则自动取消。
(2). 新店，如果商品在十天内没有上传c;自动发送消息提醒。
(3). 用户注册成功后，三天内未登录的，短信提醒。
(4). 用户发起退款三天内未处理的，通知有关操作人员。
(5). 预订会议后所有参与者都需要在预定时间点前十分钟通知参加会议。
这些场景都有特点，需要在事件发生后或之前指定的时间点完成任务，如： 发生订单生成事件十分钟后检查订单支付状态，然后关闭未付订单；似乎使用定时任务，轮询数据，每秒检查一次取出需要处理的数据，然后处理不就完成了吗？
如果数据量相对较少，确实可以这样做例如：对于“如果账单在一周内未付款，则自动结算”的需求， 如果时间没有严格限制，但宽松意义上的一周，然后每晚运行一个定时任务，检查所有未付账单，这确实是一个可行的计划。
但对于数据量相对较大的时效性强的场景，如：“如果订单在十分钟内未支付，则关闭“”c;短期内未支付的订单数据可能有很多，在活动期间，它甚至可以达到数百万甚至数千万的水平，显然不可取这么大的数据量还是轮询的。c;所有订单的检查很可能在一秒钟内无法完成，同时，它会给数据库带来巨大的压力c;不能满足业务要求，性能低下。
但对于数据量相对较大的时效性强的场景，如：“如果订单在十分钟内未支付，则关闭“”c;短期内未支付的订单数据可能有很多，在活动期间，它甚至可以达到数百万甚至数千万的水平，对于如此庞大的数据量，仍然使用轮询显然是不可取的，很有可能在一秒钟内无法完成所有订单的检查，同时，它会给数据库带来巨大的压力c;不能满足业务要求，性能低下。
以上，Rabbitmq介绍，欢迎讨论。