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