理论修炼之RabbitMQ，消息队列服务的稳健者

Posted 2021-09-07 dotNET跨平台

• ????欢迎点赞 ：???? 收藏 ⭐留言 ???? 如有错误敬请指正，赐人玫瑰，手留余香！

• ????本文作者：由webmote 原创，首发于 【掘金】

• ????作者格言：生活在于折腾，当你不折腾生活时，生活就开始折腾你，让我们一起加油！????????????

???? 序言

在ETCD节有讲过，对于架构师来说，对中间件的理论研究和熟悉不是过分的要求，以前大意了，主要偏向应用层了，今天就来学习RabbitMQ，这个消息队列服务的稳健者。

当然由于RabbitMQ内容比较丰富，因此这里先阐述下消息组件的几种模式，然后注重于连接管理。其他章节后续也许会进一步学习，有所得必和大家分享。

???? 01. RabbitMQ支持的几种队列模式

还是这个图精简，一下子就看完了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可能会不太一样，因此谨慎参考。

RabbitMQ 支持的所有协议都是基于 TCP 的，并维持长连接（每个协议操作不打开新连接）以提高效率。

当不再需要连接时，应用程序必须关闭它们以节省资源。否则可能出现连接泄露问题，有最终耗尽其目标资源节点的风险。

如果我们使用rabbitmq的监控面板，请注意:RabbitMQ 记录所有发送至少 1 字节数据的入站客户端连接。不会记录在没有任何活动的情况下打开的连接。

利用监控面板，可以轻松监控连接的泄露情况。

当然如果频繁打开关闭连接，对系统的性能也会造成影响，我们也可以监控是否频繁打开关闭连接。

发布消息的连接可能速度很快，但读和处理消息可能很慢，导致速度不匹配。这时，会自动触发背压式流，这时候读消息不受影响，但写受到流控控制，导致速度放慢。

.net client 和 java client的sdk均支持连接故障自动恢复，因此编程者几乎不用做太多工作。

虽然标准的sdk提供了连接池管理，但并非最优。而 spring 框架提供了丰富的连接池二次封装，其可以管理单链接多通道或多连接多通道模式的连接池，也提供了发布确认等相关封装。

作为.net 开发者，我们只有羡慕的份了，当然仿照其写个.net版的也应该可以，不过这个能力要求有点高，我试试写一个看看。

???? 03 强一致性方案

为了保证消息中间件的强一致性，RabbitMQ提供了集群镜像功能，交换机和队列持久化，以及发布和订阅消息的确认（ack）机制，因此我们如果需要强一致性，那么避免不了和这些技术打打交道。

通过发送消息、推送消息的确认ack方案，虚线表示，的确提升了消息投递、消费的准确性。

并且确认ack均支持异步批量方案，因此数据的读写吞吐量不用担心受到影响。

生产者在采用批量ack时，可以适当开启缓存，缓存待确认的消息，可以完美解决ack确认问题。

???? 04. 小结

RabbitMQ的内容非常多，这里仅仅介绍了一些很小的要点，后续有时间仍需要继续学习！

例行小结，理性看待！

结的是啥啊，结的是我想你点赞而不可得的寂寞。????????????

????都看到这了，还在乎点个赞吗？

????都点赞了，还在乎一个收藏吗？

????都收藏了，还在乎一个评论吗？