Azure Service Bus消息泵是否真的是事件驱动的？

所以我们最近一直在研究Azure Service Bus，我们对是否应该使用无限循环轮询队列/订阅或者是否应该使用OnMessage回调/消息泵function感到困惑。 什么会执行更少的操作，从而降低成本？

理想情况下，我们需要一个事件驱动的系统，因此我们不会浪费操作，而且通常只是一种更好的方法。

我的问题是，使用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页面上的注释具有“无限循环”和“每个接收操作是可计费事件”这一事实有点可怕。

而且，我并不是真的担心它会花多少钱/多少钱，我更感兴趣的是让它尽可能高效。

Answer 1

我没有使用过OnMessage，但问题让我感兴趣，所以我做了一些挖掘。

我的理解是，OnMessage方法只是将处理来自队列的消息的一些常见问题封装起来，以便为您提供一种更清晰/更简单的方法来解决这个问题。 因此，不是在轮询周围编写所有脚手架，而是可以更多地关注“推送式/事件驱动”实现（消息泵模型）。

所以你是正确的，因为它基本上只是一个调用Receive（）的循环 – 所以使用默认的超时，轮询的数量将是相同的，因此成本相同。

我发现了这些参考文献：

http://fabriccontroller.net/introducing-the-event-driven-message-programming-model-for-the-windows-azure-service-bus/

http://www.flyersoft.net/?p=971 – 检查评论，因为这涵盖了与您相同的问题。

那么主题/订阅和队列是一样的，还是它实际上是订阅的事件驱动而不是队列？

我不是100％，但我根据我的研究得出的假设是它是相同的，而且只是文档不清楚的情况。