天蓝色云队列的可扩展性

Question

在当前项目中，我们目前并排使用 8 个工作角色机器，它们的实际工作方式与 azure 预期的略有不同。

系统简介：

• 每个工作人员最多启动 8 个进程，这些进程实际连接到云队列并处理消息
• 每个进程访问三个不同的云队列以收集用于不同目的（增量识别、备份、元数据）的消息
• 每条消息都会导致 WCF 调用 ERP 系统以收集信息并最终将检索到的响应添加到 ReDis 缓存中
• 由于成本和性能的原因，许多较小的机器都选择了这种方法。 24 台单核机器对 ERP 系统的调用速度为 400 次/秒，而 8 台具有 8 个进程的四核机器的调用速度超过 800 次/秒。

现在问题是：即使增加机器数量以将性能提高到 1200 次调用/秒，我们也遇到了 Cloud Queue 的中断。在同一时刻，80% 的机器进程不再处理消息。

这里有两个问题：

1. 这些进程无法进行远程调试，但可以使用dile 获取一些信息。
2. 我们使用 Cloud Queue 的 GetMessages 方法从队列中获取最多 4 条消息。 Cloud Queue 总是以 0 条消息回复。重新连接云队列没有帮助。

重启工人确实有帮助，但很快就会导致同样的问题。 我们是否达到了 Cloud Queue 可扩展性的自然终点并应该切换到服务总线？

更新：

我还没有完全理解这个问题，我在the natual borders of Cloud Queue中描述过。

总结一下：

• TCP 连接数令人印象深刻。实际上太令人印象深刻（数百）
• 回到原来的内存大小让系统再次正常运行

Answer 1

花了一些时间来解决这个问题：

先总结一下存储账户的使用情况：

• 我们每天都大量使用 Blob 存储。
• Azure 开箱即用提供的“正常”诊断也使用相同的存储帐户。
• 一些控制进程使用小表来存储和读取信息，大约每小时一次。 20 分钟
• 每秒可能有多达 800 个调用尝试增加数量以计算对 ERP 系统的调用。

当我们发现存储帐户负载过重时，我们将其拆分。

• 现在有 3 个物理存储帐户处理 2 个队列。
• 原来的仍然保持高达 800/s 的调用增加计数器
• 诊断仍在原始诊断中
• 控制信息也已移动

系统现在运行了 2 周，运行良好。我们从中学到了几件事：

• 不，基础架构“不只是在那里”，而且不会无休止地扩展。
• 即使我们认为我们没有使用“那么多”总结，我们也使用了相当多且不受控制的。
• 网络中没有任何“最佳实践”可以讲述完整的故事。特别是。当开始使用存储帐户时，MS 的指南会很有帮助

存储中的异常处理非常糟糕。即使存储帐户被过度使用，我也希望出现某种异常，而不仅仅是在没有任何周围信息的情况下返回零消息 在此处阅读完整的故事：natural borders of cloud storage scalability

更新： 可扩展性有很多影响。您可能对Azure Service Bus: Massive count of listeners and senders 感兴趣，以了解更多陷阱。

Answer 2

根据我的经验，我能够从 Azure 云队列中获得比服务总线更好的原始性能，但服务总线具有更好的企业功能（可靠、主题等）。 Azure Cloud Queue 每个队列的处理速度应高达 2K/秒。

https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/

如果有一些自然分区键，您也可以尝试分区到多个队列。

确保您的进程没有某种真正的罪魁祸首线程死锁。您可以通过在队列挂起时连接到队列并尝试从队列中提取消息来进行测试。如果可行，那是您的流程，而不是队列。

还可以看看这个以设置其他一些监视器： https://azure.microsoft.com/en-us/documentation/articles/storage-monitor-storage-account/