基建狂魔，RabbitMQ，消息队列服务的稳健者，java架构师面试答案

========================

还是这个图精简，一下子就看完了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确认问题。