理论修炼之RabbitMQ，消息队列服务的稳健者
这是我参与8月更文挑战的第12天，活动详情查看：8月更文挑战java
- 📢欢迎点赞 ：👍 收藏 ⭐留言 📝 若有错误敬请指正，赐人玫瑰，手留余香！
- 📢本文做者：由webmote 原创，首发于 【掘金】
- 📢做者格言： 生活在于折腾，当你不折腾生活时，生活就开始折腾你，让咱们一块儿加油！💪💪💪
🎏 序言
在ETCD节有讲过，对于架构师来讲，对中间件的理论研究和熟悉不是过度的要求，之前大意了，主要偏向应用层了，今天就来学习RabbitMQ，这个消息队列服务的稳健者。web
固然因为RabbitMQ内容比较丰富，所以这里先阐述下消息组件的几种模式，而后注重于链接管理。其余章节后续也许会进一步学习，有所得必和你们分享。spring
🎏 01. RabbitMQ支持的几种队列模式
仍是这个图精简，一会儿就看完了6种模式。shell
🎏 01.1 简单队列模式
1个生产者，1个消费者。这种模式下消费者是按照消息的生产顺序严格进行消费的，能够看做是严格顺序消息队列。编程
🎏 01.2 工做队列
1个生产者，多个消费者，消费者按照次序逐次把消息排放到各个消费者。所以默认状况下，消费的调度并非按照工做量来的，而是按照顺序公平调度来的。缓存
幸运的是RabbitMQ提供了参数，能够修改使用带有prefetch_count=1设置的Channel#basic_qos方法 。这使用basic.qos协议方法告诉 RabbitMQ 一次不要给一个工人多个消息。或者，换句话说，在处理并确认前一条消息以前，不要向工做人员发送新消息。相反，它会将它分派给下一个不忙的工人。markdown
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的内容很是多，这里仅仅介绍了一些很小的要点，后续有时间仍须要继续学习！
例行小结，理性看待！
结的是啥啊，结的是我想你点赞而不可得的寂寞。😳😳😳
👓都看到这了，还在意点个赞吗？
👓都点赞了，还在意一个收藏吗？
👓都收藏了，还在意一个评论吗？