消息中间件-RabbitMq

消息中间件也可以称消息队列，是指用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程的通信。
使用场景
异步处理、流量削峰、限流、缓冲、排队、最终一致性、消息驱动等需求的场景都可以使用消息中间件。

自定义消息中间件

BlockingQueue（阻塞队列）是java中常见的容器，在多线程编程中被广泛使用。
当队列容器已满时生产者线程被阻塞，直到队列未满后才可以继续put；
当队列容器为空时，消费者线程被阻塞，直至队列非空时才可以继续take。

如果使用自定义的中间件，没有集群，没有分布式，玩儿法太单一，不能满足企业级应用的要求。。。
比如：
消息有没有持久化？
怎么确定消息一定能发送成功？
怎么确定消息一定能被消费成功？
高并发下的性能怎么样？
系统可靠吗？
有没有Pub/Sub模式？
有没有考虑过限流？

当前业界比较流行的开源消息中间件包括：ActiveMQ、RabbitMQ、RocketMQ、Kafka、ZeroMQ等，其中应用最为广泛的要数RabbitMQ、RocketMQ、Kafka这三款。

RabbitMQ开始是用在电信业务的可靠通信的，也是少有的几款支持AMQP协议的产品之一。
优点：

1. 轻量级，快速，部署使用方便
2. 支持灵活的路由配置。RabbitMQ中，在生产者和队列之间有一个交换器模块。根据配置的路由规则，生产者发送的消息可以发送到不同的队列中。路由规则很灵活，还可以自己实现。
3. RabbitMQ的客户端支持大多数的编程语言。

缺点：

1. 如果有大量消息堆积在队列中，性能会急剧下降
2. RabbitMQ的性能在Kafka和RocketMQ中是最差的，每秒处理几万到几十万的消息。如果应用要求高的性能，不要选择RabbitMQ。
3. RabbitMQ是Erlang开发的，功能扩展和二次开发代价很高。

JMS规范和AMQP协议

JMS规范

消息是JMS中的一种类型对象，由两部分组成：报文头和消息主体。
报文头包括消息头字段和消息头属性。字段是JMS协议规定的字段，属性可以由用户按需添加。

• JMS报文头全部字段
  
  消息主体则携带着应用程序的数据或有效负载。

1. 简单文本(TextMessage)
2. 可序列化的对象(ObjectMessage)
3. 属性集合(MapMessage)
4. 字节流(BytesMessage)
5. 原始值流(StreamMessage)
6. 无有效负载的消息(Message)。

• JMS模式

点对点模式

一个生产者向一个特定的队列发布消息，一个消费者从该队列中读取消息。这里，生产者知道消费者的队列，并直接将消息发送到消费者的队列，概括为：

1. 一条消息只有一个消费者获得
2. 生产者无需在接收者消费该消息期间处于运行状态，接收者也同样无需在消息发送时处于运行状态。
3. 每一个成功处理的消息要么自动确认，要么由接收者手动确认

发布订阅模式

1. 支持向一个特定的主题发布消息。
2. 0或多个订阅者可能对接收特定消息主题的消息感兴趣。
3. 发布者和订阅者彼此不知道对方。
4. 多个消费者可以获得消息

在发布者和订阅者之间存在时间依赖性。

1. 发布者需要建立一个主题，以便客户能够订阅。
2. 订阅者必须保持持续的活动状态以接收消息，否则会丢失未上线时的消息。
3. 对于持久订阅，订阅者未连接时发布的消息将在订阅者重连时重发。
   Destination destination = new ActiveMQQueue(destinationName)，Destination被称作队列（Queue）
   Pub/Sub：Destination destination = new ActiveMQTopic(destinationName);
   Destination被称作主题（Topic)

AMQP协议

AMQP全称高级消息队列协议（Advanced Message Queuing Protocol），是一种标准，类似于JMS，兼容JMS协议。目前RabbitMQ主流支持AMQP 0-9-1，3.8.4版本支持AMQP 1.0。

AMQP中的概念

• Publisher：消息发送者，将消息发送到Exchange并指定RoutingKey，以便queue可以接收到指定的消息。
• Consumer：消息消费者，从queue获取消息，一个Consumer可以订阅多个queue以从多个queue中接收消息。
• Server：一个具体的MQ服务实例，也称为Broker。
• Virtual host：虚拟主机，一个Server下可以有多个虚拟主机，用于隔离不同项目，一个Virtualhost通常包含多个Exchange、Message Queue。
• Exchange：交换器，接收Producer发送来的消息，把消息转发到对应的Message Queue中。
• Routing key：路由键，用于指定消息路由规则（Exchange将消息路由到具体的queue中），通常需要和具体的Exchange类型、Binding的Routing key结合起来使用。
• Bindings：指定了Exchange和Queue之间的绑定关系。Exchange根据消息的Routing key和Binding配置（绑定关系、Binding、Routing key等）来决定把消息分派到哪些具体的queue中。这依赖于Exchange类型。
• Message Queue：实际存储消息的容器，并把消息传递给最终Consumer。

3.3.4 AMQP客户端实现JMS客户端
RabbitMQ的JMS客户端用RabbitMQ Java客户端实现，既与JMS API兼容，也与AMQP 0-9-1协议兼容。
局限性

• RabbitMQ JMS客户端不支持某些JMS 1.1功能：
• JMS客户端不支持服务器会话。
• XA事务支持接口未实现。
• RabbitMQ JMS主题选择器插件支持主题选择器。队列选择器尚未实现。
• 支持RabbitMQ连接的SSL和套接字选项，但仅使用RabbitMQ客户端提供的（默认）SSL连接协议。
• RabbitMQ不支持JMS NoLocal订阅功能，该功能禁止消费者接收通过消费者自己的连接发布的消息。可以调用包含NoLocal参数的方法，但该方法将被忽略。

RabbitMQ使用amqp协议，JMS规范仅对于Java的使用作出的规定，跟其他语言无关，协议是语言无关的，只要语言实现了该协议，就可以做客户端。如此，则不同语言之间互操作性得以保证。

RabbitMq介绍

RabbitMQ，俗称“兔子MQ”（可见其轻巧，敏捷），是目前非常热门的一款开源消息中间件，不管是互联网行业还是传统行业都广泛使用（最早是为了解决电信行业系统之间的可靠通信而设计）。

1. 高可靠性、易扩展、高可用、功能丰富等
2. 支持大多数（甚至冷门）的编程语言客户端。
3. RabbitMQ遵循AMQP协议，自身采用Erlang（一种由爱立信开发的通用面向并发编程的语
   言）编写。
4. RabbitMQ也支持MQTT等其他协议。

RabbitMQ具有很强大的插件扩展能力，官方和社区提供了非常丰富的插件可供选择：https://www.rabbitmq.com/community-plugins.html

RabbitMQ Exchange类型

RabbitMQ常用的交换器类型有： fanout 、 direct 、 topic 、 headers 四种。

Fanout

会把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中，如图：

Direct

direct类型的交换器路由规则很简单，它会把消息路由到那些BindingKey和RoutingKey完全匹配的队列中，如下图：

Topic

topic类型的交换器在direct匹配规则上进行了扩展，也是将消息路由到BindingKey和RoutingKey相匹配的队列中，这里的匹配规则稍微不同，它约定：

BindingKey和RoutingKey一样都是由".“分隔的字符串；BindingKey中可以存在两种特殊字符“*”和“#”，用于模糊匹配，其中”*“用于匹配一个单词，”#"用于匹配多个单词（可以是0个）。

RabbitMQ数据存储

1. 持久化消息和非持久化消息。
2. 这两种消息都会被写入磁盘。
   持久化消息在到达队列时写入磁盘，同时会内存中保存一份备份，当内存吃紧时，消息从内存中清除。这会提高一定的性能。

非持久化消息一般只存于内存中，当内存压力大时数据刷盘处理，以节省内存空间。
RabbitMQ存储层包含两个部分：队列索引和消息存储

队列索引：rabbit_queue_index

索引维护队列的落盘消息的信息，如存储地点、是否已被给消费者接收、是否已被消费者ack等。每个队列都有相对应的索引。

消息存储：rabbit_msg_store

消息以键值对的形式存储到文件中，一个虚拟主机上的所有队列使用同一块存储，每个节点只有一个。存储分为持久化存储（msg_store_persistent）和短暂存储（msg_store_transient）。持久化存储的内容在broker重启后不会丢失，短暂存储的内容在broker重启后丢失。
store使用文件来存储，后缀为.rdq，经过store处理的所有消息都会以追加的方式写入到该文件中，当该文件的大小超过指定的限制（file_size_limit）后，将会关闭该文件并创建一个新的文件以供新的消息写入。文件名从0开始进行累加。在进行消息的存储时，RabbitMQ会在ETS（Erlang Term
Storage）表中记录消息在文件中的位置映射和文件的相关信息。

消息（包括消息头、消息体、属性）可以直接存储在index中，也可以存储在store中。最佳的方式是较小的消息存在index中，而较大的消息存在store中。

队列结构

通常队列由rabbit_amqqueue_process和backing_queue这两部分组成，
rabbit_amqqueue_process负责协议相关的消息处理，即接收生产者发布的消息、向消费者交付消息、处理消息的确认（包括生产端的confirm和消费端的ack）等。

对于普通没有设置优先级和镜像的队列来说，backing_queue的默认实现是
rabbit_variable_queue，其内部通过5个子队列Q1、Q2、delta、Q3、Q4来体现消息的各个状态。

在系统负载较高时，消息若不能很快被消费掉，这些消息就会进入到很深的队列中去，这样会增加处理每个消息的平均开销。因为要花更多的时间和资源处理“堆积”的消息，如此用来处理新流入的消息的能力就会降低，使得后流入的消息又被积压到很深的队列中，继续增大处理每个消息的平均开销，继
而情况变得越来越恶化，使得系统的处理能力大大降低。

发送端确认机制

RabbitMQ 回传给生产者的确认消息中的deliveryTag 字段包含了确认消息的序号，另外，通过设置channel.basicAck方法中的multiple参数，表示到这个序号之前的所有消息是否都已经得到了处理了。生产者投递消息后并不需要一直阻塞着，可以继续投递下一条消息并通过回调方式处理ACK响应。如果 RabbitMQ 因为自身内部错误导致消息丢失等异常情况发生，就会响应一条nack(Basic.Nack)命令，生产者应用程序同样可以在回调方法中处理理该 nack 命令。

1. 使用事务提交
2. 同步方式的发送端的单个Publisher Confirm模式waitForConfirms()
3. 同步方式的发送端的批量Publisher Confirm机制waitForConfirms
4. 异步confirm

channel.addConfirmListener(new ConfirmListener(){
    @Override
    public void handleAck(long deliveryTag, boolean multiple) throws IOException {
        System.out.println("[AsynConfirmSend] handleAck : deliveryTag = " + deliveryTag + " multiple = " + multiple);
    }
    @Override
    public void handleNack(long deliveryTag, boolean multiple) throws IOException {
        System.out.println("[AsynConfirmSend] handleNack : deliveryTag = " + deliveryTag + " multiple = " + multiple);
    }
});

持久化存储机制

持久化是提高RabbitMQ可靠性的基础，否则当RabbitMQ遇到异常时（如：重启、断电、停机等）数据将会丢失。主要从以下几个方面来保障消息的持久性：

1. Exchange的持久化。通过定义时设置durable 参数为ture来保证Exchange相关的元数据不丢失。
2. Queue的持久化。也是通过定义时设置durable 参数为ture来保证Queue相关的元数据不丢失。
3. 消息的持久化。通过将消息的投递模式 (BasicProperties 中的 deliveryMode 属性)设置为 2即可实现消息的持久化，保证消息自身不丢失。

consumer ACK

RabbitMQ在消费端会有Ack机制，即消费端消费消息后需要发送Ack确认报文给Broker端，告知自己是否已消费完成，否则可能会一直重发消息直到消息过期（AUTO模式）。

1. 采用NONE模式，消费的过程中自行捕获异常，引发异常后直接记录日志并落到异常恢复表，再通过后台定时任务扫描异常恢复表尝试做重试动作。如果业务不自行处理则有丢失数据的风险
2. 采用AUTO（自动Ack）模式，不主动捕获异常，当消费过程中出现异常时会将消息放回Queue中，然后消息会被重新分配到其他消费者节点（如果没有则还是选择当前节点）重新被消费，默认会一直重发消息并直到消费完成返回Ack或者一直到过期
3. 采用MANUAL（手动Ack）模式，消费者自行控制流程并手动调用channel相关的方法返回Ack

消息限流

当消息投递速度远快于消费速度时，随着时间积累就会出现“消息积压”。消息中间件本身是具备一定的缓冲能力的，但这个能力是有容量限制的，如果长期运行并没有任何处理，最终会导致Broker崩 溃，而分布式系统的故障往往会发生上下游传递，连锁反应那就会很悲剧…

1. RabbitMQ 可以对内存和磁盘使用量设置阈值，当达到阈值后，生产者将被阻塞(block)，直到对应项指标恢复正常。全局上可以防止超大流量、消息积压等导致的Broker被压垮。
   在/etc/rabbitmq/rabbitmq.conf中配置磁盘可用空间大小：
2. RabbitMQ 还默认提供了一种基于credit flow 的流控机制，面向每一个连接进行流控。当单个队列达到最大流速时，或者多个队列达到总流速时，都会触发流控。触发单个链接的流控可能是因为connection、channel、queue的某一个过程处于flow状态，这些状态都可以从监控平台看到。
3. RabbitMQ中有一种QoS保证机制，可以限制Channel上接收到的未被Ack的消息数量，如果超过这个数量限制RabbitMQ将不会再往消费端推送消息。这是一种流控手段，可以防止大量消息瞬时从Broker送达消费端造成消费端巨大压力（甚至压垮消费端）。比较值得注意的是QoS机制仅对于消费端推模式有效，对拉模式无效。

可靠性分析

在使用任何消息中间件的过程中，难免会出现消息丢失等异常情况，这个时候就需要有一个良好的机制来跟踪记录消息的过程（轨迹溯源），帮助我们排查问题。 在RabbitMQ 中可以使用Firehose 功能来实现消息追踪Firehose 可以记录每一次发送或者消费消息的记录，方便RabbitMQ 的使用者进行调试、排错等。

RabbitMQ 可以对消息和队列两个维度来设置TTL。
任何消息中间件的容量和堆积能力都是有限的，如果有一些消息总是不被消费掉，那么需要有一种过期的机制来做兜底。
目前有两种方法可以设置消息的TTL。

1. 通过Queue属性设置，队列中所有消息都有相同的过期时间。
2. 对消息自身进行单独设置，每条消息的TTL 可以不同。
   如果两种方法一起使用，则消息的TTL 以两者之间较小数值为准。通常来讲，消息在队列中的生存时间一旦超过设置的TTL 值时，就会变成“死信”(Dead Message)，消费者默认就无法再收到该消息。

死信队列

在定义业务队列时可以考虑指定一个 死信交换机，并绑定一个死信队列。当消息变成死信时，该消息就会被发送到该死信队列上，这样方便我们查看消息失败的原因。
DLX，全称为Dead-Letter-Exchange，死信交换器。消息在一个队列中变成死信（Dead Letter）之后，被重新发送到一个特殊的交换器（DLX）中，同时，绑定DLX的队列就称为“死信队列”。
以下几种情况导致消息变为死信：

1. 消息被拒绝（Basic.Reject/Basic.Nack），并且设置requeue参数为false；
2. 消息过期；
3. 队列达到最大长度。
   对于RabbitMQ 来说，DLX 是一个非常有用的特性。它可以处理异常情况下，消息不能够被消费者正确消费(消费者调用了Basic.Nack 或者Basic.Reject)而被置入死信队列中的情况，后续分析程序可以通过消费这个死信队列中的内容来分析当时所遇到的异常情况，进而可以改善和优化系统。

RabbitMQ集群

RabbitMQ集群允许消费者和生产者在RabbitMQ单个节点崩溃的情况下继续运行，并可以通过添加更多的节点来线性扩展消息通信的吞吐量。当失去一个RabbitMQ节点时，客户端能够重新连接到集群中的任何其他节点并继续生产和消费。
RabbitMQ集群中的所有节点都会备份所有的元数据信息，包括：

1. 队列元数据：队列的名称及属性；
2. 交换器：交换器的名称及属性；
3. 绑定关系元数据：交换器与队列或者交换器与交换器之间的绑定关系；
4. vhost元数据：为vhost内的队列、交换器和绑定提供命名空间及安全属性。

镜像队列模式

前面我们讲了，RabbitMQ内置的集群模式有丢失消息的风险，“镜像队列”可以看成是对内置默认集群模式的一种高可用架构的补充。可以将队列镜像（同步）到集群中的其他broker上，相当于是多副本冗余。如果集群中的一个节点失效，队列能自动地切换到集群中的另一个镜像节点上以保证服务的可用性，而且消息不丢失。
在RabbitMQ镜像队列中所谓的master和slave都仅仅是针对某个queue而言的，而不是node。一个queue第一次创建所在的节点是它的master节点，其他节点为slave节点。如果master由于某种原因失效，最先加入的slave会被提升为新的master。无论客户端请求到达master还是slave，最终数据都是从master节点获取。

负载均衡-HAProxy

将客户端的连接和操作的压力分散到集群中的不同节点，防止单个或几台服务器压力过大成为访问的瓶颈，甚至宕机。HAProxy是一款开源免费，并提供高可用性、负载均衡以及基于TCP和HTTP协议的代理软件，可以
支持四层、七层负载均衡，经过测试单节点可以支持10W左右并发连接。