蔚蓝云队列的可伸缩性
在当前的项目中，我们目前使用了8台工作在一起的工作人员角色机器，这些机器的工作方式与azure可能期望的略有不同。
系统简介：
- 每个工作人员启动最多8个进程，这些进程实际上连接到云队列并处理消息。
- 每个进程访问三个不同的云队列，用于收集用于不同目的的消息(增量识别、备份、元数据)。
- 每条消息都会导致对ERP系统的WCF调用，以收集信息，并最终在ReDis缓存中添加撤回的响应。
- 由于成本和性能的原因，这种方法已经被许多较小的机器所选择。当24台单核机器对ERP系统执行400次调用/秒时，8台四核机器和8个进程将执行800次以上的调用/秒。
现在要问的问题是:当增加机器数量以将性能提高到1200次/秒时，我们就经历了云队列的中断。在同一时刻，80%的机器进程不再处理消息。
这里我们有两个问题：
- 对于这些进程来说，远程调试是不可能的，但是可以使用迪尔获取一些信息。
- 我们使用云队列的GetMessages方法从队列中获取多达4条消息。云队列总是用0条消息回答。重新连接云队列没有帮助。
重新启动工人确实有帮助，但很快就会导致同样的问题。我们是否达到了云队列的可伸缩性的自然极限，并且应该切换到服务总线？
更新
我还不能完全理解这个问题，我用云队列的自然边界描述了这个问题。
概括地说：
- TCP连接的计数令人印象深刻。实际上太令人印象深刻了(数百人)
- 回到原来的内存大小，让系统再次正常运行。
回答 2
Stack Overflow用户
发布于 2016-01-22 09:22:13
根据我的经验，我能够从Azure云队列中获得比服务总线更好的原始性能，但是服务总线具有更好的企业特性(可靠、主题等)。Azure Cloud队列应处理每个队列最多2K/秒。
https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/
如果有一些自然的分区键，也可以尝试将分区划分到多个队列。
确保您的进程没有某种类型的线程死锁，这才是真正的罪魁祸首。当队列出现挂起并试图从队列中提取消息时，您可以通过连接到队列来测试这一点。如果这样做有效，这是您的进程，而不是队列。
还可以看看这个来设置一些其他监视器：https://azure.microsoft.com/en-us/documentation/articles/storage-monitor-storage-account/
Stack Overflow用户
发布于 2016-02-22 08:14:41
解决这个问题需要一些时间：
首先，概述存储帐户的使用情况：
- 我们每天都会大量使用blob储藏室。
- Azure提供的“正常”对角线也使用相同的存储帐户。
- 一些控制过程使用小表来存储和读取信息，每小时一次，大约20分钟。
- 可能会有多达800个电话/s试图增加一个数来计数一个ERP系统的呼叫。
当认识到存储帐户是在沉重的负荷下，我们把它分开。
- 现在有三个物理存储帐户，其中有2个队列。
- 原来的一个仍然保持800/s的要求增加柜台。
- 诊断学还在原版上
- 控制信息也已被移动。
这个系统现在运行了2周，工作起来很有魅力。我们从中学到了很多东西：
- 不，基础设施“不只是在那里”，而且它不会无休止地扩展。
- 即使我们认为我们没有使用“那么多”总结，我们使用了相当严重和不受控制。
- 在网络中没有任何“最佳实践”来讲述完整的故事。Esp。当开始使用存储帐户时，MS的指南将非常有用。
存储中的异常处理非常糟糕。即使存储帐户被过度使用，我也希望会有某种异常，而不仅仅是在没有任何周围信息的情况下返回零消息，在这里阅读完整的故事：云存储可伸缩性的自然边界。
更新:可伸缩性有很多影响。您可能对Azure服务总线:大量的听众和发送者感兴趣，以了解更多的陷阱。
https://stackoverflow.com/questions/34942856
复制相似问题
腾讯云开发者
