Azure 存储队列与服务总线队列-轮询/成本问题

我有一个轻微的哲学问题。我们使用存储队列来处理“票据”。我们实现这一点的方式是，我们有一个后台服务（工作者角色），它轮询存储队列，并确定是否有任何票据要处理。我们工作的性质是季节性的。这意味着不会一直有票需要处理。我们面临的问题是-由于多个工作角色实例不断轮询存储队列，因此我们会产生成本影响，因为太多的GetMessage（）调用

我遇到了服务总线队列，它具有基于事件的功能。这里我们有OnMesage（）的概念，每当服务总线队列上有新消息可用时，就会调用它

但我的问题是-OnMessage（）是否继续并在内部调用Receive（）？这意味着它只是语法糖，在内部仍在进行轮询，在服务总线队列的情况下是否也会有成本影响

---

对此的任何见解都会有所帮助

Azure Service Bus客户端正在使用长轮询从代理检索消息。

---

默认情况下，设置为1分钟或消息到达时。因此，如果您有一条显示时间早于1分钟的消息，则将检索该消息，并将进行另一次1分钟的轮询

OnMessage

/

MessageHandler

也不例外。它是在低级接收操作之上的更高级抽象。

基于，我倾向于说OnMessage调用在内部接收。虽然我找不到任何证据来证明，谢谢肖恩。这很有帮助。这是否意味着每次OnMessage（）调用我都要支付1次传输费？确实如此。相反，您可以查看EventGrid通知来替换消息泵。这取决于您使用的传输方式。如果您使用HTTP API，那么是的，它将使用长轮询。但是如果您使用AMQP，它将使用持久连接，并将事件推送到客户端。AMQP上的Azure Service Bus不会将消息推送到客户端。客户端使用长轮询。可以肯定的是，TCP上的AMQP和WebSocket都是这样。RabbitMQ将消息推送到使用者，而不是ASB。