所以我们最近一直在研究Azure Service Bus，我们是否应该使用无限循环来轮询队列/订阅或者是否应该使用OnMessage回调/我们有点困惑消息泵功能。什么会执行更少的操作，从而降低成本？
理想情况下，我们需要一个事件驱动的系统，这样我们就不会浪费操作，而且它通常只是一种更好的方法。
我的问题是，使用的OnMessage定义为＆＃34;在事件驱动的消息泵中处理消息＆＃34;真的是事件驱动的？
如果你看一下这个页面（QueueClient.OnMessage）：https://msdn.microsoft.com/library/azure/microsoft.servicebus.messaging.queueclient.onmessage.aspx你会注意到底部的注释，它说明它基本上是一个无限循环的包装器，它调用了接收（） 方法。这对我来说听起来不是事件驱动的。
现在，如果您查看此页面（SubscriptionClient.OnMessage）： https://msdn.microsoft.com/en-us/library/azure/dn130336.aspx，该评论不存在。那么主题/订阅和队列是一样的，还是实际上是订阅事件驱动而不是队列？
为什么他们甚至说它是事件驱动的，当它显然不是？ QueueClient.OnMessage页面上的注释具有单词＆＃34;无限循环＆＃34;和＆＃34;每次接收操作都是可计费的事件＆＃34;有点可怕。
另外，我并不真正关心它的成本是多少/几乎没有，我更感兴趣的是尽可能提高效率。
答案 0 :(得分：4)
我没有使用OnMessage，但问题让我感兴趣，所以我做了一些挖掘。
我的理解是，OnMessage方法只是将处理来自队列的消息的一些常见问题封装起来，以便为您提供一种更清晰/更简单的方法来解决这个问题。因此，不是在轮询周围编写所有脚手架，而是可以更多地关注＆＃34;推送式/事件驱动＆＃34;实施（消息泵模型）。
所以你是正确的，因为它基本上只是一个调用Receive（）的循环 - 所以使用默认的超时，轮询的数量是相同的，因此成本相同。
我看到了这些参考文献：
http://www.flyersoft.net/?p=971 - 检查评论，因为这涵盖了与您相同的问题。
主题/订阅和队列也是如此，或者是它 实际上是订阅的事件驱动而不是队列？
我不是100％，但我根据我的研究得出的假设是相同的，而且只是文档不清楚的情况。