因此，我们最近一直在研究 Azure 服务总线，对于是否应该使用无限循环来轮询队列/订阅，或者是否应该使用 OnMessage 回调/消息泵功能，我们有点困惑。什么将执行更少的操作，从而降低成本？
理想情况下，我们需要一个事件驱动的系统，这样我们就不会浪费操作，而且这通常是一种更好的方法。
我的问题是，使用定义为“在事件驱动的消息泵中处理消息”的 OnMessage 真的是事件驱动的吗？
如果您看一下此页面(QueueClient.OnMessage):https://msdn.microsoft.com/library/azure/microsoft.servicebus.messaging.queueclient.onmessage.aspx您会注意到底部的注释，它指出它基本上是调用 Receive() 方法的无限循环的包装器。对我来说，这听起来不太是事件驱动的。
现在，如果您查看此页面(SubscriptionClient.OnMessage): https://msdn.microsoft.com/en-us/library/azure/dn130336.aspx ，该注释不存在。那么主题/订阅和队列是否相同，或者实际上订阅是事件驱动的，但队列不是？
为什么他们甚至说它是事件驱动的，而事实显然不是？事实上，QueueClient.OnMessage页面上的注释有“无限循环”和“每个接收操作都是一个计费事件”的字样，这有点吓人。
此外，我并不真正关心这两种方式会花费多少/很少，我更感兴趣的是使其尽可能高效。
最佳答案
我没有使用过 OnMessage，但这个问题让我感兴趣，所以我做了一些挖掘。
我的理解是，OnMessage 方法只是封装了一些与处理队列中的消息有关的常见问题，为您提供一种更干净/更简单的方法来完成此操作，而无需担心很多。因此，您可以更多地关注“类似推送/事件驱动”的实现(消息泵模型)，而不是围绕轮询编写所有脚手架。
所以你是正确的，因为它基本上仍然只是一个调用 Receive() 的循环 - 因此使用默认超时，轮询数量将相同，因此成本也相同。
我遇到了这些引用资料:
http://www.flyersoft.net/?p=971 - 也请检查评论，因为这涵盖了与您相同的问题。
So is it the same for topics/subscriptions and queues or is it actually event-driven for subscriptions but not for queues?
我不是100%，但根据我的研究，我的假设是相同的，只是文档不清楚的情况。
关于c# - Azure 服务总线消息泵真的是事件驱动的吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35060623/