RabbitMQ 是否应该 一个 channel 对应 一个 queue?

发布于 2022-09-11 23:24:26 字数 671 浏览 25 评论 0

看了一下公司以前的项目, 一个项目就创建了一个 connection 和一个 channel , 一个 channel 承担了好几个 queue 的发布和消费.
但是项目也还算稳定. 现在有新的项目要写, 我觉得这应该不好吧...
好像看到过有人说过

1 connection per app, 1 channel per thread, 1 consumer per channel.

( 由于我用的是 node , 不存在 per thread , 不过也好理解~ )
由于不知道这个说法是出自何处, 文档找了一下也没找到. 而且也好奇需要发布到多个 queue 的时候, 是否需要创建多个 channel 呢, 所以想知道大家都是怎么做的...

目前我的想法是, 一个 consumer 创建一个 channel, 但是纠结是所有的 queue 共用一个 channel 来发布消息, 还是为每个 queue 创建一个独立的 channel. 希望有人能指点一下.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

慈悲佛祖 2022-09-18 23:24:26

Consumer 确实最好是一个 Channel 一个 Queue,但这不是硬性要求;Producer 则没这个限制。

主要原因是你得明白 Channel 起了什么作用,它实质上是屏蔽了 Connection 的细节,让开发者不用去管 TCP 层面上的事儿,同时基于 NIO 可以使得 Connection 的 TCP 能够被复用,减少了 TCP 连接建立的开销。

(题外话,所有 Channel 共用一个 Connection 并不适用全部情况,有些场景下反而会降低性能。所以你说 1 Connection per App 并不是绝对的。)

至于 1 Channel per Thread,是因为 Channel 本身不是线程安全的,这个很好理解,不多展开。

1 Consumer per Channel,是因为如果一个 Consumer 在一个 Channel 中正在监听某一个 Queue 的消息,那么这个 Consumer 是不能在这个 Channel 中同时去处理另一个 Queue 的,出于消费速度的考虑所以需要开辟多个 Channel,如果你本身没那么大消息吞吐量,也可以共用一个 Channel;而 Producer 是不存在这个问题的。

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文