概述
本示例程序全部来自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的不同方案;
- direct exchange: 匹配2个routingKey(即routingKey和bingingKey)是否相等,相等时才进行消息路由;
- fanout exchange: 忽略routingKey,会将Message路由到所有绑定的Queue;
- topic exchange: routingKey格式形如
aaa.bbb.xxx
、*.ccc.dd.#
,类似正则表达式匹配; - 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: 单生产者-单消费者
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: 发布/订阅
- 消费广播到多个消费者进行消费;
- 使用fanout pattern;
application.properties配置
spring.profiles.active=pub-sub, receiver , sender
详细描述参见:发布/订阅详细
demo4: 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
- 使用 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
结构图
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)
- 消息不停的发送到消费端消费,无需等待消费端任何确认;
缺点:
- 可能造成消费端不堪重负;
手动模式
- basic.ack: 肯定的确认;
- basic.nack: 否定的确认(RabbitMQ对AMQP 0-9-1的扩展),支持消息
批量确认
; - 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:自动确认模式可以产生最佳的传送速率;
应避免:
自动确认模式
;手动确认模式
+无限制的prefetch
;
结论:
情况1
和情况2
都可能导致交付但未来得及处理
的Message增加,增大RAM的消耗;
推荐值:
prefetch
: 100~300,可以有效提高吞吐量,并避免RAM消耗过多的风险;
消费失败或连接中断: 自动重新reQueue
当消息发送给消费端后,如果出现如下情况,则消息会重新reQueue
,会被再次发送;
- TCP连接中断;
- 消费端挂掉:无法进行消息确认;
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中,保证消息不丢失的唯一方法,就是使用事务;
- 开启Channel事务;
- 发送消息,提交事务;
类似消费端的应答确认机制
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.