========================
还是这个图精简,一下子就看完了6种模式。
🎏 01.1 简单队列模式
==============
1个生产者,1个消费者。这种模式下消费者是按照消息的生产顺序严格进行消费的,可以看作是严格顺序消息队列。
🎏 01.2 工作队列
============
1个生产者,多个消费者,消费者按照次序逐次把消息排放到各个消费者。因此默认情况下,消费的调度并不是按照工作量来的,而是按照顺序公平调度来的。
幸运的是RabbitMQ提供了参数,可以修改使用带有prefetch_count=1设置的Channel#basic_qos方法 。这使用basic.qos协议方法告诉 RabbitMQ 一次不要给一个工人多个消息。或者,换句话说,在处理并确认前一条消息之前,不要向工作人员发送新消息。相反,它会将它分派给下一个不忙的工人。
channel.basic_qos(prefetch_count= 1 )
复制代码
🎏 01.3 发布、订阅模式
===============
也是1个生产者,多个消费者,不过与上面方案不同的是每一个消费者都有自己的一个队列。
生产者将消息直发送到交换机,每个队列都要绑定到交换机。有几种可用的交换类型:direct、topic、headers 和fanout。我们将关注最后一个——它就是广播(fanout)
因此无论交换机绑定多少队列,交换机总会保证消息被广播给每一个队列。
🎏 01.4 路由模式
============
仍然是多个消费者,生产者嘛,就不一定了。 这里生产者把消息发送到 direct类型的交换机上。该交换机按照绑定的Key路由消息到固定的队列。
🎏 01.5 主题模式
============
主题模式相比路由模式,其更灵活,按照订阅的主题建立相关队列,交换机按照主题路由消息到各个队列。
这里一条消息如果负责多个队列的规则,则消息被路由分发到多个队列。当然如果多个规则都匹配一条消息,在一个队列内这条消息也仅被路由1次。
主题可以支持通配符*和#。
🎏 01.6 RPC模式
=============
大家都知道RPC是远程过程调用,其可以返回调用后执行的结果值,因此通过RPC模式,可以利用RabbitMQ构建一个基于RPC通讯的分布式微服务系统。
🎏 02 客户端连接
===========
这里的连接介绍基于.net client sdk,当然java的客户端也是类似。但其他客户端sdk可能会不太一样,因此谨慎参考。
Rab
《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》
【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享
bitMQ 支持的所有协议都是基于 TCP 的,并维持长连接(每个协议操作不打开新连接)以提高效率。
当不再需要连接时,应用程序必须关闭它们以节省资源。否则可能出现连接泄露问题,有最终耗尽其目标资源节点的风险。
如果我们使用rabbitmq的监控面板,请注意:RabbitMQ 记录所有发送至少 1 字节数据的入站客户端连接。不会记录在没有任何活动的情况下打开的连接。
利用监控面板,可以轻松监控连接的泄露情况。
当然如果频繁打开关闭连接,对系统的性能也会造成影响,我们也可以监控是否频繁打开关闭连接。
发布消息的连接可能速度很快,但读和处理消息可能很慢,导致速度不匹配。这时,会自动触发背压式流,这时候读消息不受影响,但写受到流控控制,导致速度放慢。
.net client 和 java client的sdk均支持连接故障自动恢复,因此编程者几乎不用做太多工作。
虽然标准的sdk提供了连接池管理,但并非最优。而 spring 框架提供了丰富的连接池二次封装,其可以管理单链接多通道或多连接多通道模式的连接池,也提供了发布确认等相关封装。
作为.net 开发者,我们只有羡慕的份了,当然仿照其写个.net版的也应该可以,不过这个能力要求有点高,我试试写一个看看。
🎏 03 强一致性方案
============
为了保证消息中间件的强一致性,RabbitMQ提供了集群镜像功能,交换机和队列持久化,以及发布和订阅消息的确认(ack)机制,因此我们如果需要强一致性,那么避免不了和这些技术打打交道。
通过发送消息、推送消息的确认ack方案,虚线表示,的确提升了消息投递、消费的准确性。
并且确认ack均支持异步批量方案,因此数据的读写吞吐量不用担心受到影响。
生产者在采用批量ack时,可以适当开启缓存,缓存待确认的消息,可以完美解决ack确认问题。