【rabbitmq】rabbitmq概念解析--消息确认--示例程序

概述

本示例程序所有来自rabbitmq官方示例程序，rabbitmq-demo；
官方共有6个demo，针对不一样的语言（如 C#，Java，Spring-AMQP等），都有不一样的示例程序；
本示例程序主要是Spring-AMQP的参考示例，若是须要其余语言的参考示例，能够参考官网；

rabbitmq模拟器

模拟器

rabbitmq简介

核心架构图

AMQP 0-9-1 Model Explained

重要语法说明

• producer或publisher: 消息生产者/发布者，即：产生消息的；
• Exchange：producer或publisher只会将message发送到Exchange，目前有4种不一样的Exchange类型；
• Queue：消息队列，全部的消费者都是直接从Queue获取Message并消费；
• Binging：链接Exchange和Queue的纽带，决定Exchange如何路由消息到不一样的Queue；
• routingKey：生产者-->message-->Exchange，须要指定一个key，叫作routingKey;
• routingKey：Exchange-->Binging-->Queue，Binging有一个Key值，叫routingKey或bingingKey;
• bingingKey：Exchange-->Binging-->Queue，Binging有一个Key值，bingingKey;

核心理解

4种不一样的Exchange，对routingKey的解释都不相同；
对routingKey的不一样解释，决定了Exchange路由Message到Queue的不一样方案；

1. direct exchange： 匹配2个routingKey（即routingKey和bingingKey）是否相等，相等时才进行消息路由；
2. fanout exchange： 忽略routingKey，会将Message路由到全部绑定的Queue；
3. topic exchange： routingKey格式形如aaa.bbb.xxx、*.ccc.dd.#，相似正则表达式匹配；
4. headers exchange：

---

jar包说明

• Java版本：
  Java版本使用以下jar（说明：如果使用）：

<dependency>
    <groupId>com.rabbitmq</groupId>
    <artifactId>amqp-client</artifactId>
    <version>4.0.2</version>
</dependency>

• Spring-AMQP版本：
  Spring AMQP 官方详细文章
  使用Profile配置各个demo的运行选择，当
  使用以下Jar包：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-amqp</artifactId>
</dependency>

demo1： 单生产者-单消费者

• Java版本：单生产者单消费者
  程序位置：java.demo1包下面

• spring-amqp版本：单生产者单消费者
  application.properties配置

spring.profiles.active=hello-world, sender, receiver

---

demo2: 单生产者-多消费者

Work queues官方示例

application.properties配置

spring.profiles.active=work-queues, sender, receiver
#spring.profiles.active=work-queues, sender
#spring.profiles.active=work-queues, receiver

详细描述参见：单生产者-多消费者详细

---

demo3: 发布/订阅

Publish/Subscribe官方示例

• 消费广播到多个消费者进行消费；
• 使用fanout pattern；

application.properties配置

spring.profiles.active=pub-sub, receiver , sender

详细描述参见：发布/订阅详细

---

demo4: Routing

Routing官方示例

Direct exchange 模式进行route结构图

a message goes to the queues whose binding key exactly matches the routing key of the message;（相等时才路由）

Multiple bindings

两个Queue使用相同的BingingKey(black) ==> 效果相似于：发布/订阅模式（demo3）；

完整的结构图

application.properties配置

pring.profiles.active=routing, receiver , sender

详细描述参见：发布/订阅详细

---

demo5: Topics

Topics官方示例

• 使用 Topic exchange实现；
• 发送到Topic exchange的routingKey必须知足必定要求：用"."分割的words列表，如：*.aaa.bbb.# ；
• BingingKey和routingKey有相同的格式要求；
• * : 能够匹配一个word；
• #: 能够匹配0个或多个words；

application.properties配置

pring.profiles.active=topics, receiver , sender

详细描述参见：Topics

---

demo6： RPC over RabbitMQ

RPC官方示例

结构图

application.properties配置

spring.profiles.active=rpc,server
#spring.profiles.active=rpc,client

详细描述参见：RPC

---

消费端确认

Delivery Identifiers: Delivery Tags

消费者注册后，rabbitmq将消息交付给消费者时，都会带有一个“Delivery Tags”，这个是惟一的ID标识，id以整数的递增的方式实现。

Acknowledgement Modes（消费端）

自动确认模式

• 发送以后，就认为是发送成功(fire-and-forget)
• 消息不停的发送到消费端消费，无需等待消费端任何确认；

缺点：

• 可能形成消费端不堪重负;

手动模式

1. basic.ack: 确定的确认；
2. basic.nack: 否认的确认(RabbitMQ对AMQP 0-9-1的扩展),支持消息批量确认;
3. basic.reject：否认的确认，消息消费失败后，直接从broker中将消息delete，不支持批量确认；

Acknowledging Multiple Deliveries at Once(消息批量确认)

• 一次确认多个消息发送，而不是每个消息单独确认；
• basic.reject：不具有该功能；
• basic.nack: 具有该功能；

实现方式

• multiple field： 设置为true；

示例

假设：在Channel（ch）上有5,6,7,8这4个delivery tags未确认；

• 状况1，delivery_tag=8 & multiple=true： 则5,6,7,8这4个tags都将被确认；
  
• 状况2，delivery_tag=8 & multiple=false：则只有8被确认，而5,6,7将不会被被确认；

Channel Prefetch Count (QoS)[能够设置消费端消费的速率]

• 消息消费是异步完成的，手动确认也是异步的；
• 有一部分消息是被消费了，可是还将来得及确认：但愿控制未被确认消息的size，防止无界的缓存；
• prefetch count：使用basic.qos方法设置该值能够控制未被确认消息的max size；
• 当达到该最大值时，rabbitmq将中止交付消息进行消费；
• 仅对basic.qos方法有效，对basic.get方法无效；

示例

假设：在Channel(Ch)上有5,6,7,8共4个未被确认的消息，且ch的prefetch count=4；
结果：rabbitmq将不会再交付任何消息到该Channel上，除非有消息被确认；

消费确认选择，prefetch设置以及吞吐量

• 状况1：增大prefetch：提升向消费者传递消息的速度;
• 状况2：自动确认模式能够产生最佳的传送速率;

应避免：

1. 自动确认模式；
2. 手动确认模式 + 无限制的prefetch；

结论：

• 状况1和状况2均可能致使交付但将来得及处理的Message增长，增大RAM的消耗；

推荐值：

• prefetch: 100~300，能够有效提升吞吐量，并避免RAM消耗过多的风险；

消费失败或链接中断： 自动从新reQueue

当消息发送给消费端后，若是出现以下状况，则消息会从新reQueue，会被再次发送；

1. TCP链接中断；
2. 消费端挂掉：没法进行消息确认；

Client Errors: Double Acking and Unknown Tags

消费端没法对同一个消息确认超过一次，当超过一次以后，将抛出Channel error: PRECONDITION_FAILED - unknown delivery tag XXXX

总结

• 每一个交付给消费端的消息，都有一个惟一的标识delivery tag；
• 自动消息确认；
• 手动消息确认：每一个消息单独确认和批量消息确认;
• prefetchCount：能够控制消息端的吞吐量，避免消费端消费过慢，产生RAM大量消耗；
• 失败重传：TCP链接中断或消费端挂掉，都会引发消息从新入队列，从新消费(手动消息确认时)；
• 没法对同一个消息进行2次或2次以上的确认，不然会抛出异常；

---

发送端确认

Channel事务

• 不推荐使用： 会严重下降吞吐量；

在 AMQP 0-9-1中，保证消息不丢失的惟一方法，就是使用事务；

1. 开启Channel事务；
2. 发送消息，提交事务；

相似消费端的应答确认机制

• confirm.select: 应用于Channel时，表示使用确认模式；
• 事务和确认模式没法共存：两者只能选择其一；

确认模式 (confirm.select)

• 发送端使用confirm.select;
• broker发送basic.ack来确认Message已被处理；
• delivery-tag： 消息序列，具备惟一性；
• multiple=true： 用于设置批量消息确认；
• 没法保证消息什么时候被确认；
• 确认模式：消息要么被confirmed（OK），要么被nack(fail)，且only once；

Java示例：(发送端发送大量messages，使用确认模式)
程序-确认模式

否认确认

异常状况时，服务端没法处理消息，则broker发送basic.nack来进行否认确认；

应答延时和持久化消息

• 仅当消息被持久化到disk以后，才会发送basic.ack应答；
• 吞吐量提升建议：异步处理应答、批量发送消息;

应答顺序

当使用异步发送和持久化消息时，broker对消息的确认顺序可能和发送者的消息发送顺序不一致；

发送确认 + 保证交付

• 消息持久化： 并不能保证消息不丢失（在写入disk前broker就挂掉）；

---

限制

Delivery tag is a 64 bit long value, and thus its maximum value is 9223372036854775807.Since delivery tags are scoped per channel, it is very unlikely that a publisher or consumer will run over this value in practice.

参考

Consumer Acknowledgements and Publisher Confirms