文章目录
- 1.消费者模型
- 2.生产者-消费者模型注意事项
- 2.1资源释放顺序问题
- 2.2消费者的声明问题
- 2.3虚拟机和用户的权限问题
- 3.七种工作模式
- 3.1简单模式
- 3.2工作模式
- 3.3发布/订阅模式
- 3.4路由模式
- 3.5通配符模式
- 3.6RPC通信
- 3.7发布确认
1.消费者模型
之前学习的这个消息队列的快速上手,只学习了生产者的这个代码编写,并且可以看到这个生产者生产的这个消息的查看;
今天补充一下这个消费者的:这个消费者的和生产者的在很多的地方都是相似的,,例如前面的这个建立连接,开发信道之类的,就是这个消费者进行这个消费消息的时候是对于这个handleDelivery方法进行重写
1) | username这个表示的是我们的admin的名字(也就是我们的用户名字) |
---|---|
2) | password是我们创建这个用户的时候设置的密码(不是我们的登录密码) |
3) | virtualhost就是我们的虚拟主机,这个虚拟主机管理我们创建的这些用户; |
4) | 5672就是消息队列上面的这个默认的端口号; |
5) | sethost就是我们的云服务器的公网ip地址(我自己是用的云服务器); |
下面的这个就是idea的控制台上面打印的这个信息:
这个时候,我们去这个查看:发现数据全部都被释放了,但是原本我们是有很多的信息的,他却只打印了一个信息,因此我们可以设置这个休眠的过程,让这个消费者打印所有的消息;
首先,我们还是需要创建消息,就是让这个生产者进行生产(因为现在已经全部被释放了),我们可以设置一个循环,多生产一些;
这个时候页面会进行自动刷新,我们的这个生产的内容消息就会显示出来:
消费者休眠之后,控制台查看:我们可以发现使用这个休眠之后,信息全部显示出来:
2.生产者-消费者模型注意事项
2.1资源释放顺序问题
下面的这个就是想要解释我们的资源的释放的问题;
下面的这个是先关闭我们的信道,然后是断开这个生产者和消费者之间的这个链接;
如果我们逆向操作,就是把这个释放资源的先后顺序进行调整,这个时候就会出现问题,这个主要是因为我们的连接断开的时候默认这个信道就关闭了;
因此,我们可以先关闭这个信道,再断开连接,但是不可以断开连接之后关闭信道;
2.2消费者的声明问题
下面的这个声明队列的这个内容是可以省略的(针对于消费者而言的);
前提是我们的这个队列是存在的,这个时候我们的33行指定了这个queue,这个时候不会报错,因为我们即使没有声明,33行使用的时候也是可以找到这个queue的;
但是如果我们把这个queue删除了,就是这个不存在了,这个时候我们进行声明,33行进行使用,这个时候也不会报错,相反,使用的时候会根据我们的这个33行的代码创建这个channel出来;
如果我们的这个queue不存在,我们也不生命,在33行直接使用,这个时候就会报错,因为根本找不到这个队列;
2.3虚拟机和用户的权限问题
1)还是之前说过的这个问题:就是我们的一个虚拟机可以对于多个用户进行管理,这个时候我们需要保证我们操作的这个用户是可以有虚拟机管理的这个权限的,否则是无法进行这个生产和消费的过程的;
2)一般我们日常学习是使用一个虚拟主机,在这个虚拟主机上面对于多个用户进行管理,而且我们的这个用户名密码也需要相互对应,否则也是无法进行消息的发送和接受的;
3.七种工作模式
3.1简单模式
简单模式就是我们上面实现的这个快速上手的案例:只有一个生产者,一个消费者的模式;
P:producer就是生产者;
C:comsumer就是消费者;
Quene:消息队列,对于信息进行缓存,生产者的消息放到这个消息队列里面,消费者从这个消息队列里面取出来消息;
3.2工作模式
这个就是工作模式:一个生产者,多个消费者,生产者生产的消息,分配给所有的这个消费者,但是每一个消费者只是获取这个消息里面的一部分内容;
适用场景:集群环境下面的异步处理;
例如我们只有一个12306,但是又很多的这个用户,这个时候12306就会把这个消息不加重复的给到每一个消费者,也就是我们的用户;
3.3发布/订阅模式
这个x表示的是交换机;
这个时候我们的这个c1和c2消费者接受的就是这个生产者的全部内容;
例如这个p生产的内容是10个消息,这个时候10个消息就会给c1一份,给c2一份,而不是像上面的这个工作模式(工作模式里面的这个消费者加起来的总和只有一份,这个发布模式是每一个消费者都是一份,这个就是两者之间的区别之一);
另外一个区别也是显而易见的,就是我们的交换机,交换机主要是下面的几种类型:
1)fanout:广播,把消息交给所有绑定了交换机的队列,我们的这个发布订阅模式使用的就是这个类型的交换机(这个类型就是不进行任何筛选,只要我们有联系,我的这个消息就会给你一份);
2)direct:定向,这个就是把消息给到指定的这个队列里面去,3.4里面的路由模式使用的这个类型的交换机;
3)topic:通配符,把消息给指定的符合通配符要求的队列里面去,也就是下面的这个3.5里面的交换机的类型;
除此之外,我们需要了解一下这个绑定规则:
1)RoutingKey:这个表示的就是我们的生产者和交换机之间的这个绑定的规则;
2)Binding Key:这个表示的就是我们的路由器和消费者之间的这个绑定的规则;
下面会针对于routingKey和biningkey展开介绍和说明;
3.4路由模式
路由模式就是上面的这个发布订阅模式的变种,只不过是有了一定的这个筛选的标准和规则,这个下面的a,b,c就是对应的选择标准;
例如我们之前学习的这个日志的等级:error,warning,info就可以视为是这个a,b,c,符合这个error级别的消息就会到这个c1里面去,符合这个warning和info级别的就回到这个c2消费者里面去;
3.5通配符模式
和上面的路由模式,这个使用的就是模糊匹配,上面的是相等才可以,我们这个是符合条件就可以,比路由模式更加灵活,使用与需要灵活的处理和进行消息的过滤的场景;
*表示的就是一个字符,#表示的就是一个或者多个字符,这个就是通配符的具体的含义;
3.6RPC通信
1)这个下面就是我们的客户端和服务端,没有生产者和消费者;
2)客户端发送消息到这个指定的队列上面,消息属性里面有这个reply和correlation,这个correlation就是最后和接收到的消息进行校验的,reply就是告诉我们的服务器把返回的消息放到这个指定的队列里面去;
3)我们的服务器就是把消息放到这个指定的毁掉队列reply_to里面去,客户端收到消息之后检查这个correlation属性是不是一样的,确保这个就是自己期望的响应的内容;
3.7发布确认
这个就类似于我们学习网络通信时候的这个里面的确认应答的机制,返回一个ack;
这个是我们的生产者和我们的消息队列服务器之间进行这个消息的确认和应答,没有这个消费者的参与,因为这个就是为了确保我们的这个生产者生产的这个消息被我们的消息队列的这个服务器接收到;