Azure 服务总线消息泵真的是事件驱动的吗？答案

【问题标题】：Is Azure Service Bus message pump really event-driven?Azure 服务总线消息泵真的是事件驱动的吗？
【发布时间】：2016-05-05 18:39:45
【问题描述】：

所以我们最近一直在研究 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 页面上的注释有“无限循环”和“每个接收操作都是计费事件”的事实有点吓人。

此外，我并不真正关心这两种方法的成本是多少，我更感兴趣的是让它尽可能高效。

【问题讨论】：

【解决方案1】：

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

我的理解是，OnMessage 方法只是封装了一些与处理来自队列的消息有关的常见问题，从而为您提供一种更清洁/更简单的方式来处理它，而无需担心很多。因此，您可以更专注于“类似推送/事件驱动”的实现（消息泵模型），而不是围绕轮询编写所有脚手架。

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

我遇到了这些参考资料：

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

主题/订阅和队列是否相同？实际上是事件驱动的订阅而不是队列？

我不是 100%，但根据我的研究，我的假设是相同的，只是文档不清楚。

【讨论】：