本文以 阿里云 为基础,参考的是尚硅谷的视频:尚硅谷2021新版RabbitMQ教程 | 快速掌握MQ消息中间件
MQ(Message Queue),从字面意思上看,本质上是个队列,FIFO先入先出,只不过队列中存放的内容是 message 而已,还是一种跨进程的通信机制,用于上下游传递消息。在互联网架构中,MQ是一种非常常见的上下游"逻辑解耦 + 物理解耦"
的消息通信服务。使用了MQ之后,消息发送上游只需要依赖MQ,不用依赖其他服务。
举个例子,如果订单系统最多能处理一万次订单,这个处理能力能应付正常时段的下单时绰绰有余,正常时段我们下单一秒后就能返回结果。但是在高峰期
,如果有两万次下单操作系统是处理不了的,只能限制订单超过一万后不允许用户下单。使用消息队列作为缓冲,我们可以取消这个限制,把一秒钟内下的订单分散成一段时间来处理,这时有些用户可能在下单十几秒后才能收到下单成功的操作,但是不能比下单的体验要好。
以电商应用为例,应用中有订单系统、库存系统、物流系统、支付系统。用户创建订单后,如果耦合调用库存系统、物流系统、支付系统,任何一个子系统出现了故障,都会造成下单操作异常。当转变成基于消息队列的方式后,系统间调用的问题会减少很多,比如物流系统因为发生故障,需要几分钟来修复。在这几分钟时间里,物流系统要处理的内存被缓存在消息队列中
,用户的下单操作可以正常完成。当物流系统修复后,继续处理订单信息即可,中间下单用户感受不到物流系统的故障,提升系统的可用性。
有些服务间的调用是异步的,例如A调用B,B需要花费很长时间执行,但是A需要知道B什么时候可以执行完,以前一般有两种方式,第一种:A过一段时间去调用B的查询api查询。或者A提供一个Callback api,B执行完之后调用api通知A服务。这两种方式都不是很优雅,使用消息总线
,可以很方便的解决这个问题,A调用B服务后,只需要监听B处理完成的消息,当B处理完成后,会发送一条消息给 MQ ,MQ 会将此消息转发给A服务。这样A服务既不用循环调用B的查询api,也不用提供Callback api。同样B服务也不用做这些操作。A服务还能及时的得到异步处理成功的消息。注:使用消息总线的时候,B服务在处理请求完成之前,A服务可以去做其他的任务,而以前的两种方式A服务在B服务处理请求的时候都是处于等待状态的。
大数据的杀手锏,谈到大数据领域内的消息传输,则绕不开Kafka,这款为大数据而生的消息中间件,以其百万级别TPS的吞吐量名声大噪,迅速成为大数据领域的宠儿,再数据采集、传输、存储的过程中发挥着举足轻重的作用。目前已经被 LinkedIn、Uber、Twitter、Netflix等大公司所采纳。
RocketMQ出自阿里巴巴的开源产品,用JAVA语言实现,在设计的时候参考了Kafka,并做出了自己的一些改进。被阿里巴巴广泛应用在订单,交易,充值,流计算,消息推送,日志流处理,binlog 分发等场景。
2007年发布,是一个在 AMQP(高级消息队列协议)基础上完成的,可复用的企业消息系统,是当前最主流的消息中间件之一。
Kafka 主要特点是基于 Pull 的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输,适合产生大量数据的互联网服务的数据收集业务。 大型公司建议可以选用,如果有日志采集功能,肯定是首选Kafka了。
天生为金融互联网领域而生,对于可靠性要求很高的场景,尤其是电商里面的订单扣款,以及业务消峰,在大量交易涌入的时候,后端可能出现无法及时处理的情况。RocketMQ 在稳定性上可能更加值得信赖,这些业务场景在阿里双11已经经历了多次考验,如果你的业务有上述并发场景,建议可以选择 RocketMQ。
结合 erlang 语言本身的并发优势,性能好时效性微妙级别,社区活跃度也比较高,管理界面用起来也十分方便,如果你的数据量没有那么大,中小型公司优先选择功能比较完备的 RabbitMQ 。
RabbitMQ 是一个消息中间件:它接受并转发消息。你可以把它当做一个快递站点,当你要发送一个包裹的时候,你把你的包裹放到快递站,快递员最终会把你的快递送到收件人那里,按照这种逻辑 RabbitMQ 是一个快递站,一个快递员帮你传递快件。RabbitMQ与快递站的主要区别在于,它不处理快件而是接收,存储和转发消息数据。
生产者
交换机
队列
消费者
查询 rabbitMQ,不指定的话默认为最新版本latest:
拉取镜像:
docker pull rabbitmq:management
查看 docker 镜像列表:
Docker 容器操作:上面命令执行后,镜像就已经拉取到本地仓库了,然后可以进行容器操作,启动 RabbitMQ
# 设置账户密码运行 RabbitMQ
# -d 后台运行
# -p 映射对外开放的端口 主机端口:容器端口
# --name 指定rabbitMQ容器的名称
# -e 配置环境变量 -e RABBITMQ_DEFAULT_USER 指定用户账号
# -e RABBITMQ_DEFAULT_PASS指定账号密码
# --hostname 主机名(RabbitMQ 的一个重要注意事项是它根据所谓的节点名称存储数据,默认为主机名)
docker run -d -p 15672:15672 -p 5672:5672 -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin --name rabbitmq --hostname=rabbitmqhostone rabbitmq:management
# 不设置账户名密码运行 RabbitMQ
docker run -d -p 5672:5672 --name rabbitmq rabbitmq:management
注意, rabbitMQ 默认的账号密码是:guest/guest
# 添加一个新的用户
root@rabbitmqhostone:/# rabbitmqctl add_user 用户名 密码
# 设置用户角色
root@rabbitmqhostone:/# rabbitmqctl set_user_tags 用户名 tags/administrator
# 设置用户和角色
set_permission [-p <vhostpath>] <user> <conf> <write> <read>
rabbitmqctl set_permission -p "/" admin ".*" ".*" ".*"
# 查看当前用户和角色
root@rabbitmqhostone:/# rabbitmqctl list_users
Listing users ...
user tags
admin [administrator]
使用JAVA编写两个程序,发送单个消息的生产者和接收消息并打印出来的消费者。
P 是我们的生产者,C是我们的消费者,中间的红色框是一个队列 ==》 代表使用者保留的消息缓冲区。
例如,创建 Maven 项目并导入如下依赖:
<dependencies>
<!-- https://mvnrepository.com/artifact/com.rabbitmq/amqp-client -->
<dependency>
<groupId>com.rabbitmq</groupId>
<artifactId>amqp-client</artifactId>
<version>5.13.1</version>
</dependency>
<!-- https://mvnrepository.com/artifact/commons-io/commons-io -->
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.11.0</version>
</dependency>
</dependencies>
<build>
<plugins>
<!-- 指定jdk编译版本 -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</build>
生产者代码构建:
public class Proceducer {
//队列名称
public static final String QUEUE_NAME="hello";
public static void main(String[] args) throws IOException, TimeoutException {
//发消息
//创建一个连接工厂
ConnectionFactory factory=new ConnectionFactory();
//工厂IP,连接RabbitMQ的队列
factory.setHost("39.107.103.173");
//用户名
factory.setUsername("admin");
//密码
factory.setPassword("admin");
//设置端口号 注意 15672是RabbitMQ是后台管理界面的端口号 应该设置5672端口
factory.setPort(5672);
//创建连接
Connection connection = factory.newConnection();
//获取信道(Channel)
Channel channel = connection.createChannel();
//创建一个队列
/**
* queueDeclare(String var1, boolean var2, boolean var3, boolean var4, Map var5)
* var1:队列名称
* var2:队列里面的消息是否持久化,默认情况下消息是存储在内存中,持久化即为存储在磁盘中
* var3:该队列是否支持多个消费者进行消费,是否进行消息共享,true可以多个消费者消费(即消息共享)
* false表示只能一个消费者消费(即不进行消息共享)
* var4:是否自动删除 最后一个消费者断开连接以后 该队列是否自动进行删除
* var5:其他参数,例如:延迟消息等等
*/
channel.queueDeclare(QUEUE_NAME,false,false,false,null);
//发消息
String message="hello rabbitMQ";
/**
* 发送一个消息:
* 1.发送到哪个交换机
* 2.路由的key值 本次是队列的名称 根据routing key分发消息到队列中
* 3.其他参数信息
* 4.发送消息的消息体
*/
channel.basicPublish("",QUEUE_NAME,null,message.getBytes());
System.out.println("消息发送完毕!");
}
}
消费者队列构建:
/**
* @author wcc
* @date 2021/11/3 11:07
* 消费者,接受消息的
*/
public class Consumer {
//队列的名称,目的是接受此队列的消息
public static final String QUEUE_NAME = "hello";
public static void main(String[] args) throws IOException, TimeoutException {
//接收消息
//创建连接RabbitMQ的连接工厂
ConnectionFactory factory=new ConnectionFactory();
factory.setHost("39.107.103.173");
factory.setUsername("admin");
factory.setPassword("admin");
factory.setPort(5672);
Connection connection=factory.newConnection();
Channel channel=connection.createChannel();
//成功的消费回调
DeliverCallback deliverCallback = (consumeTag,message)->{
System.out.println(new String(message.getBody()));
};
//取消消息时的回调
CancelCallback cancelCallback= (consumerTag)->{
System.out.println("消费消息被中断");
};
//消费者接收消息
/**
* 消费者消费消息
* 1.消费哪个队列
* 2.消费成功之后是否要自动应答 true代表的是自动应答 false代表的是手动应答
* 3.消费者成功消费的回调
* 4.消费者取消消费回调
*/
channel.basicConsume(QUEUE_NAME,true,deliverCallback,cancelCallback);
}
}
**工作队列(又称任务队列)**的主要思想是避免立即执行资源密集型任务,而不得不等待它完成。相反我们安排任务在之后执行。我们把任务封装为消息并将其发送到队列。在后台运行的工作进程将弹出任务并最终执行作业。当有多个工作线程的时候,这些工作线程将一起处理这些任务。
启动两个工作线程,一个消息发送线程,我们来看看两个工作线程是如何工作的?
5.1.1、抽取工具类
public class RabbitMQUtils {
public static Channel getChannel() throws IOException, TimeoutException {
//接收消息
//创建连接RabbitMQ的连接工厂
ConnectionFactory factory=new ConnectionFactory();
factory.setHost("39.107.103.173");
factory.setUsername("admin");
factory.setPassword("admin");
factory.setPort(5672);
Connection connection=factory.newConnection();
Channel channel=connection.createChannel();
return channel;
}
}
工作线程接收消息代码:
/**
* @author wcc
* @date 2021/11/4 10:47
* 这是一个工作线程 相当于之前讲的消费者
*/
public class Worker01 {
//队列的名称
public static final String QUEUE_NAME="hello";
//接收消息
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMQUtils.getChannel();
DeliverCallback deliverCallback=(consumeTag,message)->{
System.out.println("接收到的消息:"+new String(message.getBody()));
};
CancelCallback cancelCallback=message ->{
System.out.println(message + "消费者取消消费的接口回调逻辑");
};
//消息的接收
/**
* 消费者消费消息
* 1.消费哪个队列
* 2.消费成功之后是否要自动应答 true代表的是自动应答,false代表手动应答
* 3.消费者消费成功的回调函数
* 4.消费者取消消费的回调
*/
System.out.println("C2等待接收消息...");
channel.basicConsume(QUEUE_NAME,true,deliverCallback,cancelCallback);
}
}
生产者产生代码(控制台输入数据作为消息):
/**
* @author wcc
* @date 2021/11/4 11:04
* @Description 生产者 发送大量的消息
*/
public class Task01 {
//队列名称
public static final String QUEUE_NAME="hello";
//发送大量消息
public static void main(String[] args) throws Exception{
Channel channel = RabbitMQUtils.getChannel();
//队列
channel.queueDeclare(QUEUE_NAME,false,false,false,null);
//从控制台当中接收信息
Scanner scanner=new Scanner(System.in);
while (scanner.hasNext()){
String message=scanner.next();
/**
* 发送一个消息到队列
* 1.发送到哪个交换机
* 2.路由的key值是哪个 本次是队列的名称
* 3.其他参数信息
* 4.发送消息的消息体
*/
channel.basicPublish("",QUEUE_NAME,null,message.getBytes());
System.out.println("发送消息完成:"+message);
}
}
}
通过最后两个工作线程接收消息的结果来看,工作线程是以轮询的方式来接收消息的,一个消息只能被处理一次,不能够被处理多次。
消费者完成一个任务可能需要一段时间,如果其中一个消费者处理一个长的任务并且只完成了部分突然它挂掉了,会发生什么情况。RabbitMQ 一旦向消费者传递了一条消息,便立即将消息标记为删除。在这种情况下,突然有个消费者挂掉了,我们将丢失正在处理的消息。以及后续发送给该消费者的消息,因为它无法接收到。
为了保证消息在接收过程中不丢失,RabbitMQ 引入消息应答机制,消息应答就是:消费者在接收到消息并且处理该消息之后,告诉 RabbitMQ 它已经处理了,RabbitMQ 可以把该消息删除了。
6.1.1、自动应答
消息发送后立即被认为已经传送成功,这种模式需要在高吞吐量和数据传输安全性方面做权衡,因为这种模式如果消息在接收到之前,消费者那边出现连接断开或者 Channel 关闭,那么消息就丢失了,当然另一方面这种模式消费那边可以传递过载的消息,没有对传递的消息数量进行限制,当然这样有可能使得消费者这边由于接收太多还来不及处理的消息,导致这些消息的积压,最终使得内存耗尽,最终这些消费者线程被操作系统杀死,所以这种模式仅适用在消费者可以高效并以某种速率能够处理这些消息的情况下使用。
6.1.2、手动应答
手动应答的好处就是可以 批量应答并且减少网络拥堵
批量处理参数 Multiple Boolean值
如果消费者由于某些原因失去连接(其通道已经关闭,连接已经关闭或者TCP连接丢失),导致消息未发送ACK确认,RabbitMQ将了解到消息未完全处理,并将对其重新排队。如果此时其他消费者可以处理,它将很快将其重新分发给另一个消费者。这样,即使某个消费者偶尔死亡,也可以确保不会丢失任何消息。
默认消息采用的是自动应答,所以我们要想实现消息消费过程中不丢失,需要把自动应答改为手动应答。
生产者:
/**
* @author wcc
* @date 2021/11/4 15:01
* 消息在手动应答的时候是不丢失的、放回队列中重新消费
*/
public class Task02 {
//队列名
public static final String task_queue_name = "ack_queue";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMQUtils.getChannel();
//声明一个队列
channel.queueDeclare(task_queue_name,false,false,false,null);
//从控制台中输入
Scanner scanner=new Scanner(System.in);
while (scanner.hasNext()){
String message = scanner.next();
channel.basicPublish("",task_queue_name,null,message.getBytes("UTF-8"));
}
}
}
消费者:
/**
* @author wcc
* @date 2021/11/4 15:07
* 消息在手动应答的时候是不丢失、放回队列中重新消费
*/
public class Worker03 {
//队列名
public static final String task_queue_name = "ack_queue";
//接收消息
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMQUtils.getChannel();
System.out.println("C1等待接收消息处理时间较短");
DeliverCallback deliverCallback=(consumeTag,message)->{
//沉睡1秒钟
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("接收到的消息:"+new String(message.getBody(),"UTF-8"));
//手动应答策略
/**
* 1.消息的标记 tag 表示应答的是哪一个消息
* 2.是否批量应答 false:表示不批量应答信道中的消息 true:表示批量
*/
channel.basicAck(message.getEnvelope().getDeliveryTag(),false);
};
//采用手动应答 第二个参数未是否采用自动应答
channel.basicConsume(task_queue_name,false,deliverCallback,(message->{
System.out.println(message+"消费者取消消息回调");
}));
}
}
在发送者发送消息dd,发出消息之后就把C2消费者停掉,按理说该C2来处理该消息了,但是由于它处理时间较长,在还未处理完,也就是说C2还没有执行ACK代码的时候,C2被停掉了,此时会看到消息被C1接收到了,说明消息dd被重新入队了,然后分配给能处理该消息的C1处理了。
刚刚我们已经看到了如何处理任务不丢失的情况,但是如何保障当RabbitMQ服务停掉以后消息生产者发送过来的消息不丢失。默认情况下 RabbitMQ 退出由于某种原因崩溃的时候,它忽视队列和消息,除非告知它不要这样做。确保消息不会丢失需要做两件事:我们需要将队列和消息都记为持久化。
之前我们创建的队列都是非持久化的,RabbitMQ 如果重启的话,该队列就会被删除掉,如果要队列实现持久化,需要在声明队列的时候把 durable 参数设置为持久化
//让消息队队列持久化
boolean durable = true;
channel.queueDeclare(ACK_QUEUE_NAME,durable,false,false,null);
但是需要注意的就是如果之前声明的队列不是持久化的,需要把原先队列先删除,或者重新创建一个持久化的队列,不然就会出现错误。
要想让消息实现持久化需要在消息生产者修改代码,MessageProperties.PERSISTENT_TEXT_PLAIN添加这个属性。
/**
* 发送一个消息:
* 1.发送到哪个交换机
* 2.路由的key值 本次是队列的名称 根据routing key分发消息到队列中
* 3.其他参数信息
* 4.发送消息的消息体
*/
channel.basicPublish("",QUEUE_NAME,null,message.getBytes());
channel.basicPublish("",QUEUE_NAME,MessageProperties.PERSISTENT_TEXT_PLAIN,message.getBytes());
将消息标记为持久化并不能完全保证不会丢失消息。尽管它告诉 RabbitMQ 将消息保存到磁盘中,但是这里依然存在当消息刚准备存储在磁盘的时候,但是还没有存储完,消息还在缓存的一个间隔点。此时并没有真正的写入磁盘。持久性保证并不强,但是对于我们的简单任务队列而言,这已经绰绰有余了。如果需要更强有力的持久化策略,参考后边的发布确认章节。
在最开始的时候我们学习到 RabbitMQ分发消息采用的轮训分发,但是在某种场景下这种策略并不是很好,比方说有两个消费者在处理任务,其中有个消费者1处理任务的速度非常快,而另外一个消费者2处理速度却非常慢,这个时候,我们还是采用轮训分发的话就会了解到处理速度快的这个消费者1很大一部分时间都是处于空闲状态,而处理慢的那个消费者一直在干活,这种分配方式在这种情况下其实就不太好,但是 RabbitMQ 并不知道这种情况,它依然还是很公平的进行分发。
为了避免这种情况(即为了实现能者多劳),我们可以设置参数:channel.basicQos(1);
下面举个例子来证明不公平分发的实现:
生产者:
public class Task02 {
//队列名
public static final String task_queue_name = "ack_queue";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMQUtils.getChannel();
//声明一个队列
channel.queueDeclare(task_queue_name,true,false,false,null);
//从控制台中输入
Scanner scanner=new Scanner(System.in);
while (scanner.hasNext()){
String message = scanner.next();
channel.basicPublish("",task_queue_name,null,message.getBytes("UTF-8"));
}
}
}
消费者:
/**
* @author wcc
* @date 2021/11/4 15:07
* 消息在手动应答的时候是不丢失、放回队列中重新消费
*/
public class Worker03 {
//队列名
public static final String task_queue_name = "ack_queue";
//接收消息
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMQUtils.getChannel();
System.out.println("C1等待接收消息处理时间较短");
DeliverCallback deliverCallback = (consumeTag, message) -> {
//沉睡1秒钟
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("接收到的消息:" + new String(message.getBody(), "UTF-8"));
//手动应答策略
/**
* 1.消息的标记 tag 表示应答的是哪一个消息
* 2.是否批量应答 false:表示不批量应答信道中的消息 true:表示批量
*/
channel.basicAck(message.getEnvelope().getDeliveryTag(), false);
};
int preCount = 1;
channel.basicQos(preCount);
//采用手动应答 第二个参数未是否采用自动应答
channel.basicConsume(task_queue_name, false, deliverCallback, (message -> {
System.out.println(message + "消费者取消消息回调");
}));
}
}
/**
* @author wcc
* @date 2021/11/4 15:07
* 消息在手动应答的时候是不丢失、放回队列中重新消费
*/
public class Worker04 {
//队列名
public static final String task_queue_name = "ack_queue";
//接收消息
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMQUtils.getChannel();
System.out.println("C2等待接收消息处理时间较长");
DeliverCallback deliverCallback = (consumeTag, message) -> {
//沉睡1秒钟
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("接收到的消息:" + new String(message.getBody(), "UTF-8"));
//手动应答策略
/**
* 1.消息的标记 tag 表示应答的是哪一个消息
* 2.是否批量应答 false:表示不批量应答信道中的消息 true:表示批量
*/
channel.basicAck(message.getEnvelope().getDeliveryTag(), false);
};
int preCount = 1;
channel.basicQos(preCount);
//采用手动应答 第二个参数未是否采用自动应答
channel.basicConsume(task_queue_name, false, deliverCallback, (message -> {
System.out.println(message + "消费者取消消息回调");
}));
}
}
测试结果:
RabbitMQ的工作流程:意思就是如果这个任务我还没有处理完或者我还没有应答你,你先别分配给我,我目前只能处理一个任务,然后 RabbitMQ 就会把该任务分配给没有那么忙的那个空闲消费者,当然如果所有的消费者都没有完成手上的任务,队列还在不停的添加新的任务,队列有可能就会遇到队列被撑满的情况,这个时候就只能添加新的 worker 或者改变其他存储任务的策略。
本身消息的发送就是异步的,所以在任何时候,Channel 上肯定不止只有一个消息,另外,来自消费者的手动确认本质上也是异步的。因此这里本身就存在一个未确认的消息缓冲区,因此希望开发人员能限制此缓冲区的大小,以避免缓冲区里面无限制的未确认消息问题。这个时候就可以通过使用 basic.qos
方法设置预取计数值来完成的。该值定义通道上允许的未确认消息最大数量。一旦数量达到配置的数量,RabbitMQ 将停止在通道上传递更多的消息,除非至少有一个未处理的消息被确认,例如:假设在通道上有未确认的消息5、6、7、8,并且通道的预取计数设置为4,此时 RabbitMQ 将不会在该通道上再传递任何未确认的消息5、6、7、8,并且通道的预取计数设置位4,此时RabbitMQ将不会在该通道上再传递任何消息,除非至少有一个未应答的消息被ACK。比方说, tag = 6 这个消息刚刚被确认ACK,RabbitMQ 将会感知这个情况并再发送一条消息。消息应答和 QoS 预取值对用户吞吐量有重大影响。通常,增加预取将提高向消费者传递消息的速度。虽然自动应答传输效率是最佳的,但是,在这种情况下已传递但尚未处理的消息数量也会增加,从而增加了消费者的 RAM 消耗(随机存取存储器),应该小心使用具有无限预处理的自动确认模式或者手动确认模式,消费者消费了大量的消息如果没有确认的话,会导致消费者连接节点的内存消耗变大,所以找到合适的预取值是一个反复试验的过程,不同的负载取值也不同,100到300之间范围内的值通常可以提供最佳的吞吐量,并且不会给消费者带来太大的风险。预取值为1是最保守的。当然这将使得吞吐量变得很低,特别是消费者连接延迟很严重的情况下,特别是在消费者连接等待时间较长的环境中。对于大多数应用来说,稍微高一点的值将是最佳的。
生产者将信道设置成 Confirm 模式,一旦信道进入 Confirm 模式,所有在该信道上面发布的消息都将会被指派一个唯一的ID(从1开始),一旦消息被投递到所有匹配的队列之后,broker 就会发送一个确认给生产者(包含消息的唯一 ID),这就使得生产者知道消息已经正确到达目的队列了,如果消息和队列是可持久化的,那么确认消息会在消息写入磁盘之后发出,Broker 回传 basci.ack 的 multiple 域,表示到这个序列号之前的所有消息都已经得到了处理。
Confirm 模式最大的好处在于他是异步的,一旦发布一条消息,生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息,当消息最终得到确认之后,生产者应用便可以通过回调方法来处理该确认消息,如果 RabbitMQ 因为自身内部错误导致消息丢失,就会发送一条 nack 消息,生产者应用程序同样可以在回调方法中处理该 nack 消息。
这是一种简单的确认方式,它是一种同步发布确认的方式,也就是发布一个消息之后只有它被发布确认,后续的消息才能继续发布,waitForConfirmsOrDie(long)
这个方法只有在消息被确认的时候才返回,如果在指定时间范围内这个消息没有被确认那么它将抛出异常。
这种确认方式有一个最大的缺点就是:发布速度特别的慢,因为如果没有发布确认的消息就会阻塞所有后续消息的发布,这种方式最多提供每秒不超过数百条发布消息的吞吐量。当然对于某些应用程序来说这可能已经足够了。
//单个发布确认
public static void publishMessageIndividually() throws Exception{
Channel channel = RabbitMQUtils.getChannel();
//队列的声明
String queue_name = UUID.randomUUID().toString();
channel.queueDeclare(queue_name,true,false,false,null);
//开启单个发布确认模式
channel.confirmSelect();
//开始的时间
Long begin=System.currentTimeMillis();
for (int i = 0; i < MESSAGE_COUNT; i++) {
String message=i+" ";
channel.basicPublish("",queue_name,null,message.getBytes());
//单个消息马上就进行发布确认
boolean b = channel.waitForConfirms();
if(b){
System.out.println("消息发送成功"+(i+1));
}
}
//结束时间
Long end=System.currentTimeMillis();
System.out.println("发布"+MESSAGE_COUNT+"条单个确认消息,耗时:"+(end-begin));
}
上面那种单个发布确认方式非常慢,与单个发布确认消息相比,先发布一批消息然后一起确认可以极大地提高吞吐量,当然这种方式的缺点就是:当发生故障导致发布出现问题的时候,不知道是哪个消息出现问题了,我们必须将整个批处理保存在内存中,以记录重要的信息而后重新发布消息。当然这种方案仍然是同步的,也一样阻塞消息的发布。
//批量发布确认
public static void publishMessageBatch() throws Exception{
Channel channel = RabbitMQUtils.getChannel();
//队列的声明
String queue_name = UUID.randomUUID().toString();
channel.queueDeclare(queue_name,true,false,false,null);
//开启单个发布确认模式
channel.confirmSelect();
//开始的时间
Long begin=System.currentTimeMillis();
int batchSize=100;
for (int i = 1; i <= MESSAGE_COUNT; i++) {
String message=i+" ";
if(i%batchSize==0){
channel.waitForConfirms();
System.out.println("消息发送成功"+i);
}
}
//结束时间
Long end=System.currentTimeMillis();
System.out.println("发布"+MESSAGE_COUNT+"条单个确认消息,批量确认耗时:"+(end-begin));
}
异步发布确认虽然编程逻辑上比以上两个同步的发布确认要复杂,但是性价比是最高,无论是可靠性还是效率都没得说,它是利用回调函数来达到消息可靠性传递的,这个中间件也是通过函数回调来保证是否投递成功。
//异步发布确认
public static void publishMessageAsync() throws Exception{
Channel channel = RabbitMQUtils.getChannel();
//队列的声明
String queue_name = UUID.randomUUID().toString();
channel.queueDeclare(queue_name,true,false,false,null);
//开启单个发布确认模式
channel.confirmSelect();
//开始的时间
Long begin=System.currentTimeMillis();
//消息确认成功回调
/**
* 1.确认的消息标识
* 2.是否批量处理
*/
ConfirmCallback var1 = (deliveryTag,multiple) ->{
System.out.println("确认的消息:"+deliveryTag);
};
//消息确认失败回调
/**
* 1.消息的标识
* 2.是否未批量处理
*/
ConfirmCallback var2 = (deliveryTag,multiple) ->{
System.out.println("未确认的消息:"+deliveryTag);
};
//准备消息的监听器 监听哪些消息成功了,哪些消息失败了
/**
* 1.监听哪些消息成功了进行回调
* 2.监听哪些消息失败了进行回调
*/
channel.addConfirmListener(var1,var2);
//批量发送消息
for (int i = 0; i < MESSAGE_COUNT; i++) {
String message=i+" ";
channel.basicPublish("",queue_name,null,message.getBytes());
}
//结束时间
Long end=System.currentTimeMillis();
System.out.println("发布"+MESSAGE_COUNT+"条异步发布确认消息,耗时:"+(end-begin));
}
这里会出现一些问题,异步发送确认的时候,当消息发送完以后会出现确认还未结束,此时后面就是异步未确认消息,该如何处理呢?
解决方案:把未确认的消息放到一个基于内存的能被发布线程访问的队列,比如说用 ConcurrentLinkedQueue 这个队列在 confirm callbacks 与发布线程之间进行消息的传递。
//异步发布确认
public static void publishMessageAsync() throws Exception{
Channel channel = RabbitMQUtils.getChannel();
//队列的声明
String queue_name = UUID.randomUUID().toString();
channel.queueDeclare(queue_name,true,false,false,null);
//开启单个发布确认模式
channel.confirmSelect();
//开始的时间
Long begin=System.currentTimeMillis();
//线程安全有序的一个哈希表,适用于高并发的情况下
/**
* 1.轻松的将序号与消息进行关联
* 2.轻松的批量删除条目 只要给到序号
* 3.支持高并发操作
*/
ConcurrentSkipListMap<Long,String> concurrentSkipListMap = new ConcurrentSkipListMap();
//消息确认成功回调
/**
* 1.确认的消息标识
* 2.是否批量处理
*/
ConfirmCallback var1 = (deliveryTag,multiple) ->{
if(multiple){
//删除掉已经确认的消息,剩下的就是未确认的消息
//这里对headMap(int) 返回此映射的部分视图,其键值严格小于等于tokey
ConcurrentNavigableMap<Long, String> confirmed =
concurrentSkipListMap.headMap(deliveryTag);
//clear():从此映射中移除所有映射关系
confirmed.clear();
}else{
concurrentSkipListMap.remove(deliveryTag);
}
System.out.println("确认的消息:"+deliveryTag);
};
//消息确认失败回调
/**
* 1.消息的标识
* 2.是否未批量处理
*/
ConfirmCallback var2 = (deliveryTag,multiple) ->{
String message = concurrentSkipListMap.get(deliveryTag);
System.out.println("未确认的消息是:"+message+":::未确认的消息tag:"+deliveryTag);
};
//准备消息的监听器 监听哪些消息成功了,哪些消息失败了
/**
* 1.监听哪些消息成功了进行回调
* 2.监听哪些消息失败了进行回调
*/
channel.addConfirmListener(var1,var2);
//批量发送消息
for (int i = 0; i < MESSAGE_COUNT; i++) {
//此处发送消息的时候记录下所有要发送的消息 消息的总和
String message=i+" ";
concurrentSkipListMap.put(channel.getNextPublishSeqNo()-1,message);
channel.basicPublish("",queue_name,null,message.getBytes());
}
//结束时间
Long end=System.currentTimeMillis();
System.out.println("发布"+MESSAGE_COUNT+"条异步发布确认消息,耗时:"+(end-begin));
}
我们创建了一个队列,我们假设是工作队列地背后,每个任务都恰好交付给一个消费者(工作进程)。在这一部分中,我们将做一些完全不同地事情 - 我们将消息传达给多个消费者。这种模式称为 “发布 / 订阅”。
RabbitMQ 消息传递模型的核心思想是:生产者生产的消息从不会直接发送到队列。实际上,通常生产者甚至都不知道这些消息传递传递到了哪些队列中。
相反,生产者只能将消息发送到交换机(Exchange),交换机工作的内容非常简单,一方面它接收来自生产者的消息,另一方面将它们推入队列。交换机必须确切的知道如何处理收到的消息。是应该把这些消息放到特定队列还是说把它们放到许多队列中还是说应该丢弃它们。这就由交换机的类型来决定。
总共有以下类型:
直接(direct)、主题(topic)、标题(headers)、扇出(fanoyt)
在我们向消费者发送消息的时候不设置交换机的时候,但是仍然能够将消息发送到队列。所使用的交换机就是默认交换机,通过空字符串("")进行标识。
channel.basicPublish("",queue_name,null,message.getBytes());
第一个参数是交换机的名称。空字符串表示默认或者无名称交换机:消息能够路由发送到队列中其实是由 **routingKey(bindingKey)**绑定key指定的,如果它存在的话
之前的例子中我们使用的是具有特定名称的队列(还记得 hello 和 ack_queue吗?)。队列的名称对我们来说至关重要 – 我们需要指定我们的消费者去消费哪个队列的消息。
每当我们连接到 RabbitMQ 的时候,我们都需要一个全新的空队列,为此我们可以创建一个具有随机名称的队列,或者能让服务器为我们选择一个随机队列名称那就更好了。其次一旦我们断开了消费者的连接,队列将被自动删除。
什么是绑定呢?Bindbings,bindings 其实是 exchange 和 queue 之间的桥梁,它告诉我们 exchange 和哪个队列进行了绑定关系。
Fanout 这种类型非常简单。正如从名称中猜到的那样,它是将接收到的所有消息广播到它知道的所有队列中。系统中默认有些 exchange 类型。
什么叫做消息幂等性?
当出现消费者对某条消息重复消费的情况的时候,重复消费的结果与消费一次的结果是相同的,并且多次消费并未对业务系统产生任何负面影响,那么这整个过程就可实现消息幂等
。
生产者
/**
* @author wcc
* @date 2021/11/10 17:54
* 发消息给交换机
*/
public class EmitLog {
//交换机的名称
public static final String EXCHANGE_NAME="logs";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMQUtils.getChannel();
channel.exchangeDeclare(EXCHANGE_NAME,"fanout");
Scanner sc =new Scanner(System.in);
while (sc.hasNext()){
String message = sc.next();
/**
* 第一个参数:交换机名称
* 第二个参数:routing key
* 第三个参数:其他配置信息
* 第四个参数:消息数据
*/
channel.basicPublish(EXCHANGE_NAME,"",null,message.getBytes());
System.out.println("生产者发出的消息为:"+message);
}
}
}
消费者01的代码:
/**
* @author wcc
* @date 2021/11/10 15:44
* 消息的接收
*/
public class ReceiveLogs01 {
//交换机的名称
public static final String EXCHANGE_NAME="logs";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMQUtils.getChannel();
//声明一个交换机
channel.exchangeDeclare(EXCHANGE_NAME,"fanout");
//声明一个队列 临时队列
/**
* 生成一个临时的队列、队列的名称是随机的
* 当消费者断开与队列的连接的时候 队列就自动删除了
*/
String queue = channel.queueDeclare().getQueue();
//绑定交换机与队列
channel.queueBind(queue,EXCHANGE_NAME,"");
System.out.println("ReceiveLogs01等待接收消息,把接收消息打印在屏幕上....");
DeliverCallback deliverCallback=(consumeTag,message)->{
System.out.println("ReceiveLogs01控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8"));
};
channel.basicConsume(queue,true,deliverCallback,consumeTag->{});
}
}
消费者02的代码:
/**
* @author wcc
* @date 2021/11/10 15:44
* 消息的接收
*/
public class ReceiveLogs02 {
//交换机的名称
public static final String EXCHANGE_NAME="logs";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMQUtils.getChannel();
//声明一个交换机
channel.exchangeDeclare(EXCHANGE_NAME,"fanout");
//声明一个队列 临时队列
/**
* 生成一个临时的队列、队列的名称是随机的
* 当消费者断开与队列的连接的时候 队列就自动删除了
*/
String queue = channel.queueDeclare().getQueue();
//绑定交换机与队列
channel.queueBind(queue,EXCHANGE_NAME,"");
System.out.println("ReceiveLogs02等待接收消息,把接收消息打印在屏幕上....");
DeliverCallback deliverCallback=(consumeTag,message)->{
System.out.println("ReceiveLogs02控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8"));
};
channel.basicConsume(queue,true,deliverCallback,consumeTag->{});
}
}
结果如下:
](https://imgtu.com/i/IajEWD)
上一个我们的日志系统将所有的消息广播给所有消费者,对此我们想做出一些改变,例如我们希望将日志消息写入磁盘的程序仅仅接收严重错误(errors),而不存储哪些警告(warning)或者信息(info)日志消息避免浪费磁盘空间。Fanout这种交换类型并不能给我们带来很大的灵活性,它只能进行无意识的广播,在这里我们将使用 direct 这种类型来进行替换,这种类型的工作方式是,消息只能去到它绑定的 routingKey 队列中去。
在上面这种图中,我们可以看到 交换机X 绑定了两个队列,绑定类型是 direct 。队列 Q1 绑定键为 orange,队列Q2绑定键有两个:一个绑定键位 black,另一个绑定键为 green。
在这种绑定情况下,生产者发布消息到 exchange 上,绑定键为 orange 的消息会被发布到队列Q1,绑定键为 black 和 green 的消息会被发布到队列 Q2,其他消息类型的消息将被丢弃。
直接交换机还支持多重绑定
当然如果 exchange 的绑定类型是 direct ,但是它绑定的多个队列的 key 如果都相同,在这种情况下虽然绑定类型是 direct 但是它所表现的就和 fanout(散出)有点类似了,就跟广播差不多了。
代码演示:
/**
* @author wcc
* @date 2021/11/11 10:16
* 生产者
*/
public class DirectLogs {
//交换机的名称
public static final String EXCHANGE_NAME = "direct_logs";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMQUtils.getChannel();
Scanner scanner=new Scanner(System.in);
while (scanner.hasNext()){
String message=scanner.next();
/**
* 第一个参数:交换机的名称
* 第二个参数:routing key
* 第三个参数:其他配置信息
* 第四个参数:消息数据
*/
channel.basicPublish(EXCHANGE_NAME,"error",null,message.getBytes("UTF-8"));
System.out.println("生产者发送消息:"+message);
}
}
}
注意,这里要想实现直接发送的特征,只需要更改 生产者发送消息的 routingKey 即可,以此来对应不同的消费者。(一个消费者还可以支持多重绑定,即一个消费者的可以多次绑定同一个队列并设置不同的 routingKey 以此来达到多重绑定的效果)。
/**
* @author wcc
* @date 2021/11/10 21:30
* 消费者1
*/
public class ReceiveLogsDirect01 {
public static final String EXCHANGE_NAME="direct_logs";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMQUtils.getChannel();
//声明一个交换机
channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.DIRECT);
//声明一个队列
channel.queueDeclare("console", false, false, false, null);
/**
* 绑定交换机与队列
*/
channel.queueBind("console",EXCHANGE_NAME,"info");
channel.queueBind("console",EXCHANGE_NAME,"warning");
DeliverCallback deliverCallback=(consumeTag, message)->{
System.out.println("ReceiveLogsDirect01控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8"));
};
//第二个参数代表是否自动应答
channel.basicConsume("console",true,deliverCallback,consumeTag->{});
}
}
/**
* @author wcc
* @date 2021/11/10 21:30
* 消费者2
*/
public class ReceiveLogsDirect02 {
public static final String EXCHANGE_NAME="direct_logs";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMQUtils.getChannel();
//声明一个交换机
channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.DIRECT);
//声明一个队列
channel.queueDeclare("disk", false, false, false, null);
/**
* 绑定交换机与队列
*/
channel.queueBind("disk",EXCHANGE_NAME,"error");
DeliverCallback deliverCallback=(consumeTag, message)->{
System.out.println("ReceiveLogsDirect02控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8"));
};
//第二个参数代表是否自动应答
channel.basicConsume("disk",true,deliverCallback,consumeTag->{});
}
}
在上一个例子中,我们改进了日志记录系统。我们没有使用只能进行随意广播的 fanout 交换机,而是使用了 direct 交换机,从而能实现有选择性的接受日志。
尽管使用 direct 交换机改进了我们的系统,但是它仍然存在局限性 - 比方说我们想接收的日子类型有 info.base 和 info.advantage,某个队列只想要接收 info.base 的消息,那这个时候 direct 就办不到了。这个时候就出现了 topic类型 的交换机。
发送到类型是 topic 交换机的消息的 routingKey 不能随意写,必须满足一定的要求,它必须是一个单词列表,以点号分隔开。这些单词可以是任意单词,比如说:stock.usd.nyse
,nyse.vmw
。当然注意这个单词列表最多不能超过 255 个字节。
在这个规则列表中,其中有两个替换符是大家需要注意的:
当队列绑定关系是下列这种情况的时候需要引起注意:
生产者代码
/**
* @author wcc
* @date 2021/11/11 11:27
* 生产者
*/
public class EmitLogsTopic {
//交换机的名称
public static final String EXCHANGE_NAME = "topic_logs";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMQUtils.getChannel();
/**
* 与消费者的绑定关系为:
* Q1 --> 绑定的是
* 中间带 orange 带3个单词的字符串(*.orange.*)
* Q2 --> 绑定的是
* 最后一个单词是 rabbit 的3个单词(*.*.rabbit)
* 第一个单词是 lazy 的多个单词(lazy.#)
*/
Map<String,String> bindingMap = new HashMap<>();
bindingMap.put("quick.orange.rabbit","被队列Q1Q2接收到");
bindingMap.put("lazy.orange.elephant","被队列Q1Q2接收到");
bindingMap.put("quick.orange.fox","被队列Q1接收到");
bindingMap.put("lazy.brown.fox","被队列Q2接收到");
bindingMap.put("lazy.pink.rabbit","虽然满足两个绑定但只被队列Q2接收一次");
bindingMap.put("quick.brown.fox","不匹配任何绑定不会被任何队列接收到会被丢弃");
bindingMap.put("quick.orange.male.rabbit","是四个单词但不匹配任何绑定会被丢弃");
bindingMap.put("lazy.orange.male.rabbit","是四个单词但匹配Q2");
for (Map.Entry<String, String> entry : bindingMap.entrySet()) {
String key = entry.getKey();
String message = entry.getValue();
channel.basicPublish(EXCHANGE_NAME,key,null,message.getBytes("UTF-8"));
System.out.println("生产者发出消息:"+key+":"+message);
}
}
}
消费者01代码
/**
* @author wcc
* @date 2021/11/11 11:15
* 声明主题交换机以及相关队列
* 消费者1
*/
public class ReceiveLogsTopic01 {
//交换机名称
public static final String EXCHANGE_NAME = "topic_logs";
public static void main(String[] args) throws IOException, TimeoutException {
//接收消息
Channel channel = RabbitMQUtils.getChannel();
//声明交换机
channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.TOPIC);
//声明队列
channel.queueDeclare("Q1",false,false,false,null);
/**
* 第一个参数:队列名
* 第二个参数:交换机名字
* 第三个参数:routingKey
*/
channel.queueBind("Q1",EXCHANGE_NAME,"*.orange.*");
System.out.println("ReceiveLogsTopic01等待接收消息...");
DeliverCallback deliverCallback=(consumeTag, message)->{
System.out.println("ReceiveLogsTopic01控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8"));
System.out.println("接收队列:"+"Q1"+" 绑定键:"+message.getEnvelope().getRoutingKey());
};
//第二个参数代表是否自动应答
channel.basicConsume("Q1",true,deliverCallback,consumeTag->{});
}
}
消费者02代码
/**
* @author wcc
* @date 2021/11/11 11:15
* 声明主题交换机以及相关队列
* 消费者2
*/
public class ReceiveLogsTopic02 {
//交换机名称
public static final String EXCHANGE_NAME = "topic_logs";
public static void main(String[] args) throws IOException, TimeoutException {
//接收消息
Channel channel = RabbitMQUtils.getChannel();
//声明交换机
channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.TOPIC);
//声明队列
channel.queueDeclare("Q2",false,false,false,null);
/**
* 第一个参数:队列名
* 第二个参数:交换机名字
* 第三个参数:routingKey
*/
channel.queueBind("Q2",EXCHANGE_NAME,"*.*.rabbit");
channel.queueBind("Q2",EXCHANGE_NAME,"lazy.#");
System.out.println("ReceiveLogsTopic02等待接收消息...");
DeliverCallback deliverCallback=(consumeTag, message)->{
System.out.println("ReceiveLogsTopic02控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8"));
System.out.println("接收队列:"+"Q2"+" 绑定键:"+message.getEnvelope().getRoutingKey());
};
//第二个参数代表是否自动应答
channel.basicConsume("Q2",true,deliverCallback,consumeTag->{});
}
}