TCP 反压激活时 RabbitMQ C# 客户端回调？
我还没有找到一种方法来确定发布者何时因 TCP 背压（流量控制）而挂起。对于我的应用程序来说，悬挂任何线程几乎是不可接受的。如果发布操作没有很快发生，我需要能够中止它。我注意到 Pika 客户端对此有一个回调，但在 c# 客户端文档中找不到任何内容。有人有解决方案吗？我可以创建一个后台任务来进行发布，并在超时后中止线程，但这似乎很严厉，而且 thread.abort 有它自己的问题。
I haven't found a way to determine when a publisher is hung due to tcp backpressure (flow control). For my application, hanging any thread is pretty much unacceptable. I need to be able to abort the publish operation if it doesn't happen quickly. I noticed the Pika client has a callback for this, but could find nothing in the c# client docs. Does anyone have a solution for this ? I could create a background task to do the publishing, and abort the thread after some timeout, but this seems heavy handed and thread.abort has it's own problems.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
RabbitMQ 从显式流量控制切换到通过 TCP 背压进行节流的原因是为了支持更多客户端（其中许多客户端无法处理诸如channel.flow之类的异步方法）。不幸的是，它的完成方式，或者说应该完成的方式，对发布商来说是完全透明的——发布商无法知道它何时受到限制。
如果您确实对发布有严格的实时保证，那么您唯一的选择就是实施手动超时。当然，这并不能解决 RabbitMQ 过载的根本问题，因此停止发布、终止连接并打开一个新连接并不会让您再次接近发布。
因此，您要么 1) 需要修改为什么需要如此严格的发布保证，要么 2) 向 添加更多节点RabbitMQ 集群（非常简单，旨在改善这种情况）。
The reason RabbitMQ switched from explicit flow control to throttling via TCP back-pressure is to support more clients (many of which could not handle asynchronous methods like
channel.flow). Unfortunately, the way it's done, and arguably the way it should be done, is completely transparent to publishers -- there is no way for a publisher to tell when it's being throttled.If you really one hard real-time guarantees for publishing, your only choice is to implement a manual timeout. Of course, that doesn't solve the underlying issue that RabbitMQ is overloaded, so stopping the publishing, killing the connection and opening a new one will not get you closer to publishing again.
So, you either 1) need to revise why you need such strict guarantees for publishing or 2) add more nodes to the RabbitMQ cluster (which is dead-simple and is designed to improve exactly this situation).