消息队列

队列 Queue 是一种先进先出的数据结构。
生产者 发送消息1,2,3…对于消费者就会按照1,2,3…的顺序来消费。

点到点（P2P）模型

（Queue）作为消息通信载体；满足生产者与消费者模式，一条消息只能被一个消费者使用，未被消费的消息在队 列中保留直到被消费或超时。

② 发布/订阅（Pub/Sub）模型（topic）

JMS是java的消息服务,所定义的是API规范。
JMS的五种消息格式：
StreamMessage – Java原始值的数据流
MapMessage–一套名称-值对
TextMessage–一个字符串对象
ObjectMessage–一个序列化的 Java对象
BytesMessage–一个字节的数据流

消息队列主要有两点好处：
1.通过异步处理提高系统性能（削峰、减少响应所需时间）;
2.降低系统耦合性。

消息队列具有很好的削峰作用的功能——即通过异步处理，将短时间高并发产生的事 务消息存储在消息队列中，从而削平高峰期的并发事务。

因为用户请求数据写入消息队列之后就立即返回给用户了，但是请求数据在后续的业务校验、写数据库等操作中可能失败。因此使用消息队列进行异步处理之后，需要适当修改业务流程进行配合，比如用户在提交订单之后，订单 数据写入消息队列，不能立即返回用户订单提交成功，需要在消息队列的订单消费者进程真正处理完该订单之后，甚至出库后，再通过电子邮件或短信通知用户订单成功。

(2) 降低系统耦合性
我们知道如果模块之间不存在直接调用，那么新增模块或者修改模块就对其他模块影响较小，这样系统的可扩展 性无疑更好一些。
我们常见的事件驱动架构类似生产者消费者模式，在大型网站中通常用利用消息队列实现事件驱动结构。如下图所示：
消息队列使利用发布-订阅模式工作，消息发送者（生产者）发布消息，一个或多个消息接受者（消费者）订阅 消息。 从上图可以看到消息发送者（生产者）和消息接受者（消费者）之间没有直接耦合，消息发送者将消息发送 至分布式消息队列即结束对消息的处理，消息接受者从分布式消息队列获取该消息后进行后续处理，并不需要知道该 消息从何而来。对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展性设计。

消息接受者对消息进行过滤、处理、包装后，构造成一个新的消息类型，将消息继续发送出去，等待其他消息接 受者订阅该消息。因此基于事件（消息对象）驱动的业务架构可以是一系列流程。
另外为了避免消息队列服务器宕机造成消息丢失，会将成功发送到消息队列的消息存储在消息生产者服务器上， 等消息真正被消费者服务器处理后才删除消息。在消息队列服务器宕机后，生产者服务器会选择分布式消息队列服务器集群中的其他服务器发布消息。
备注： 不要认为消息队列只能利用发布-订阅模式工作，只不过在解耦这个特定业务环境下是使用发布-订阅模式的。 除了发布-订阅模式，还有点对点订阅模式（一个消息只有一个消费者），我们比较常用的是发布-订阅模式。 另外， 这两种消息模型是 JMS 提供的，AMQP 协议还提供了 5 种消息模型。

ActiveMQ 的社区算是比较成熟，但是较目前来说，ActiveMQ 的性能比较差，而且版本迭代很慢，不推荐使 用。
RabbitMQ 在吞吐量方面虽然稍逊于 Kafka 和 RocketMQ ，并发能力很强， 性能极其好，延时很低，达到微秒级。如果业务场景对并发量要求不是太高（十万级、百万级），那这四种消息队列 中，RabbitMQ 一定是你的首选。
RocketMQ 阿里出品，Java 系开源项目，源代码我们可以直接阅读，然后可以定制自己公司的MQ，接口这块不是按照标准 JMS 规范走的有些系统要迁移需要修改大量代码。
kafka 的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms 级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展。同时 kafka 好是支撑较少的 topic 数量即可，保证其超高吞吐量。 kafka 唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及 日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集。

RabbitMQ:
RabbitMQ是一个由erlang开发的AMQP(Advanved Message Queue Protocol)的开源实现。

核心概念
Message 消息，消息是不具名的，它由消息头和消息体组成。消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode（指出 该消息可能需要持久性存储）等。
Publisher 消息的生产者，也是一个向交换器发布消息的客户端应用程序。
Exchange 交换器，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。 Exchange有4种类型：direct(默认，点对点)，fanout（订阅）, topic（订阅）, 和headers（订阅），不同类型的Exchange转发消息的策略有所区别。

Queue 消息队列，用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息 可投入一个或多个队列。消息一直在队列里面，等待消费者连接到这个队列将其取走。
Binding 绑定，用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连 接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表。 Exchange 和Queue的绑定可以是多对多的关系。
Connection 网络连接，比如一个TCP连接。
Channel 信道，多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内的虚 拟连接，AMQP 命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这些动作都是通过信道完成。因为对于操作系统来说建立和销毁 TCP 都是非常昂贵的开销，所 以引入了信道的概念，以复用一条 TCP 连接。
Consumer 消息的消费者，表示一个从消息队列中取得消息的客户端应用程序。
Virtual Host 虚拟主机，表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加 密环境的独立服务器域。每个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器，拥有 自己的队列、交换器、绑定和权限机制。vhost 是 AMQP 概念的基础，必须在连接时指定， RabbitMQ 默认的 vhost 是 / 。
Broker 表示消息队列服务器实体。

运行机制：
AMQP 中的消息路由
AMQP 中消息的路由过程和 Java 开发者熟悉的 JMS 存在一些差别，AMQP 中增加了 Exchange 和 Binding 的角色。生产者把消息发布到 Exchange 上，消息最终到达队列并被 消费者接收，而 Binding 决定交换器的消息应该发送到那个队列。

Exchange 类型
Exchange分发消息时根据类型的不同分发策略有区别，目前共四种类型： direct、fanout、topic、headers 。headers 匹配 AMQP 消息的 header 而不是路由键， headers 交换器和 direct 交换器完全一致，但性能差很多， 目前几乎用不到了，所以直接看另外三种类型：

Disruptor
线程之间用于消息传递的队列。

以下是普通双向循环数组队列的实现

/**
 * 循环数组队列
 * 多线程下会有安全问题
 */
public class CircleQueue {
    private String[] items;
    private int n = 0;
    private int head=0;
    private int tail = 0;

    public CircleQueue(int capacity){
        items = new String[capacity];
        n = capacity;

    }
    //入队
    public boolean enqueue(String item){
        //队列满
        if((tail+1)%n == head){return false;}
        items[tail] = item;
        tail = (tail+1)%n;//循环
        return true;
    }
    //出队
    public String dequeue(){
        if(head == tail){return null;}
        String ret = items[head];
        head = (head+1)%n;//循环
        return ret;
    }
}

Disruptor的优化：
对于生产者来说，它往队列中添加数据之前，先申请可用空闲存储单元，并且是批量地申请连续的 n 个（n≥1）存储单元（加锁申请）。当申请到这组连续的存储单元之后，后续往队列中添加元素，就可以不用加锁了，因为这组存储单元是这个线程独享的。不过，从刚刚的描述中，我们可以看出，申请存储单元的过程是需要加锁的。
对于消费者来说，处理的过程跟生产者是类似的。它先去申请一批连续可读的存储单元（这个申请的过程也是需要加锁的），当申请到这批存储单元之后，后续的读取操作就可以不用加锁了。