我的应用程序中的每个用户都有gmail帐户。
应用程序需要与传入的电子邮件同步。
对于每1分钟的每个用户，应用程序应该询问gmail服务器是否有新内容。 99％的时间都没有什么新东西。
据我所知，gmail不提供网络摘要
为了减少来自我的服务器的负载，特别是来自DB的负载我希望以下列方式使用服务总线队列。
队列属性：
查询方法：PEEK_AND_LOCK
锁定时间：1分钟
最大交货数：X
流量：
队列侦听器从队列接收消息A并处理它。
如果没有新内容，则侦听器不会从队列中删除该消息
邮件将在锁定时间（1分钟）后再次发送
基本上不是一次又一次地向队列发送新消息以进行处理，而是将它们留在队列中并依赖于重新传递机制。
我们期待在不久的将来有许多用户（100,000-500,000），这意味着在给定时刻队列中的许多消息需要每分钟处理一次。
我假设重新传递机制主要用于错误处理，我想知道我们的设计是否合理，队列是否适合该任务？或者是否有任何其他建议来实现我们的目标。
由于
答案 0 :(得分：0)
您正在尝试将服务总线队列用作调度程序，而实际上并非如此。因此，SB Queue将成为主要瓶颈。根据您的体系结构和预期的用户数量，您会发现自己被limitations of the Service Bus queue快速阻止。例如，您只有最多100个并发连接，这意味着只有100个侦听器（假设采用长池方法）。
另一个问题可能是SB Queue的max delivery count属性。即使您现在将其设置为int.MaxValue，也不能保证Azure Team将来不会限制它。
替代解决方案可能是您实现自己的调度程序工作者角色（使用已经存在的流行工具，例如Quartz.NET）。然后你可以尝试 - 你可以在一个辅助角色中托管N个工作（实际上是执行Gmail api请求）（每个工作每X分钟运行一次），每个工作可以完全处理M个用户。如果用户数量增加，工作者角色可以轻松扩展。数字N和M可以取决于工人角色配置，并且可以在实践中确定。如果适用，只是为了节省一些资源，X可以变化，例如，根据一天中的时间（可能你不需要经常在晚上检查电子邮件）。希望它有所帮助。