「中间件」英文为middleware，是一个合成词，middle都认识，不解释了，ware表示“器皿”，“物件”的意思，中文翻译过来就是“位于中间的物体”。

在计算机中，简单可以理解为“中间件是这样的软件，它位于两个软件中间，广义的讲，这两个软件一般为应用软件和系统软件之间”。

淘宝，有代办签证这样的业务，但无论互联网还是面签，所有的签证办理机构应该是对你开放的，而且可以省去直接办理和代办的差价，但是这样的业务还是很红火。

房产交易，国家房产交易部门完全对个人开放办理，但是一些中介机构仍然在大量充当陌生人房产交易的枢纽，并赚取佣金。

电子商务，支付宝、理财通充当了人和商家之间的中转和媒介，使交易更有保障和快捷。

这三个事物中，可以抽象出什么共性呢？我试着描述一下几个特点：专业、安全、快捷、成本低，它们是我们生活中的「中间件」。

我们把签证中心，房产交易所，商家理解为操作系统的话，我们每个人相当于应用层软件。其中淘宝平台，房产交易中介，还有支付宝、理财通就是中间的软件。

在正式介绍RabbitMQ之前，我们来说说什么是消息队列（Message queue，简称MQ），从字面理解就是一个保存消息的一个容器。那么我们为何需要这样一个容器呢？其实就是为了解耦各个系统。

利用高效可靠的消息传递机制进行异步的数据传输，并基于数据通信进行分布式系统的集成。通过提供消息队列模型和消息传递机制，可以在分布式环境下扩展进程间的通信。

我们来举个例子：

有这么一个简单的场景，系统A负责生成userID，并调用系统B、C。如果系统BC频繁变化是否需要userID参数，则系统A的代码就得不断变化，如果哪天又来了系统DEF……也需要这个参数，则系统A又要加入很多业务逻辑，这样子各他系统之间就容易产生相互影响，另外大量的系统与A发生交互也容易产生问题。

加了消息队列后，A只负责产生userID，至于谁要用这个参数，怎么用？系统A不管。对这个数据感兴趣的系统自己去取用即可，各个系统之间就实现了解耦。而且解耦后，整个服务业变成了一个异步的方式，系统A产生数据后，不用依次调用BCD来累计耗时，各系统可以同时来取用消息队列的数据进行处理，加大吞吐。

1、先进先出：消息队列的顺序在入队的时候就基本已经确定了，一般是不需人工干预的。

2、发布订阅：发布订阅是一种很高效的处理方式，如果不发生阻塞，基本可以当成是同步操作。

3、持久化：持久化确保消息队列的使用不只是一个部分场景的辅助工具，而是让消息队列能像数据库一样存储核心的数据。

4、分布式：在现在大流量、大数据的使用场景下，支持分布式的部署，才能被广泛使用。消息队列的定位就是一个高性能的中间件。

分别是：

Point-to-Point，点对点通信模型。PTP是基于队列(Queue)的，一个队列可以有多个生产者，和多个消费者。消息服务器按照收到消息的先后顺序，将消息放到队列中。队列中的每一条消息，只能由一个消费者进行消费，消费之后就会从队列中移除。

特点：

P 表示为生产者 、C 表示为消费者，红色表示队列。

工作模式：一个消息生产者，一个交换器，一个消息队列，多个消费者。同样也称为点对点模式

假如我们拥有两个消费者，默认情况下，RabbitMQ 将按顺序将每条消息发送给下一个消费者，平均而言，每个消费者将获得相同数量的消息，这种分发消息的方式称为轮询。

假如有一些非常耗时的任务，某个消费者在缓慢地进行处理，而另一个消费者则空闲，显然是非常消耗资源的。

举一个例子

一个1年的程序员，跟一个3年的程序员，分配相同的任务量，明显3年的程序员处理起来更加得心应手，很快就无所事事了，但是3年的程序员拿着非常高的薪资！显然3年的程序员应该承担更多的责任，那怎么办呢？

公平分发

案例中发生上述问题的原因是 RabbitMQ 收到消息后就立即分发出去，而没有确认各个工作者未返回确认的消息数量

因此我们可以使用 basicQos 方法，并将参数 prefetchCount 设为1，告诉 RabbitMQ 我每次值处理一条消息，你要等我处理完了再分给我下一个。这样 RabbitMQ 就不会轮流分发了，而是寻找空闲的工作者进行分发。

publish-and- subscribe， 即发布订阅模型。在Pub/Sub模型中，生产者将消息发布到一个主题(Topic)中，订阅了该Topic的所有下游消费者，都可以接收到这条消息。

特点：

注意：

P 表示为生产者、 X 表示交换机、C1C2 表示为消费者，红色表示队列。

通常情况下，一个条消息只要被消费一次就行了，那么什么情况下需要所有的消费者都对这条消息进行消费呢？最典型的情况就是需要在内存中对数据进行缓存，并需要实时进行更新。

例如，笔者做过一个违禁词系统，对用户输入的评论内容进行违禁词汇检测。这个违禁词系统，部署了在N台服务器上，为了提升检测性能，每台机器都会将违禁词库全量加载到内存中，词库的更新，是通过发送MQ消息来完成的。由于采用Pub/Sub模型，每台机器的consumer，都可以接收到这条消息，直接在内存中更新敏感词库即可。

路由模式跟发布订阅模式类似，然后在订阅模式的基础上加上了类型，订阅模式是分发到所有绑定到交换机的队列，路由模式只分发到绑定在交换机上面指定路由键的队列

P 表示为生产者、 X 表示交换机、C1C2 表示为消费者，红色表示队列

配置为例，我们以 routingKey="error" 发送消息到 Exchange，则消息会路由到Queue1（amqp.gen-S9b…，这是由RabbitMQ自动生成的Queue名称）和Queue2（amqp.gen-Agl…）。如果我们以 routingKey="info" 或 routingKey="warning" 来发送消息，则消息只会路由到 Queue2。如果我们以其他 routingKey 发送消息，则消息不会路由到这两个 Queue 中。

相对于发布订阅模式，我们可以看到不再是广播似的接收全部消息，而是有选择性的消费。

topics 主题模式跟 routing 路由模式类似，只不过路由模式是指定固定的路由键 routingKey，而主题模式是可以模糊匹配路由键 routingKey，类似于SQL中 = 和 like 的关系。

P 表示为生产者、 X 表示交换机、C1C2 表示为消费者，红色表示队列

Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache顶级项目。Kafka主要为高吞吐量的订阅发布系统而设计，追求速度与持久化。kafka中的消息由键、值、时间戳组成，kafka不记录每个消息被谁使用，只通过偏移量记录哪些消息是未读的，kafka中可以指定消费组来实现订阅发布的功能。

RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。

RocketMQ是阿里开源的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。支持的客户端语言不多，目前是Java及C++，其中C++还不成熟；