我正试图在Windows Azure中设置一个全局计数器，用于跟踪一天内开始的游戏数量。每次玩家开始游戏时，都会从客户端向服务器发出Web服务调用，全局计数器将增加一。这对于数据库来说应该相当简单。。。但我想知道我如何才能有效地做到这一点。数据库方法同时适用于几百个客户端，但如果我有100000个客户端，会发生什么？
谢谢你的帮助/想法！
一年多前，这是Cloud Cover一集中的一个主题：Cloud Cover第43集-Windows Azure的可扩展计数器。他们讨论了如何创建Apaythy按钮(类似于Facebook上的Like按钮)。
Steve Marx还在一篇博客文章中详细讨论了这一点，文章的源代码为：用Windows Azure构建可扩展计数器。在这个解决方案中，他们正在执行以下操作：
- 在每个实例上，跟踪本地计数器
- 使用
Interlock.Increment修改本地计数器 - 如果计数器发生了更改，请将新值保存在表存储中(每隔几秒钟就有一个计时器执行此操作)。对于每个部署/实例，counters表中都有1条记录
- 要显示总计数，请取计数器表中所有记录的总和
好吧，有很多选择。我不知道哪一个对你最好。但我会在这里介绍一些优点和缺点，根据您的要求，您可以得出自己的结论。
最简单的答案是"将其存储"。SQL Azure和核心Azure表或博客存储选项都适合您。需要解决的一个问题是面对大规模并发时的性能，但我也鼓励您考虑正确性。你真的想要一些支持原子增量的东西来外包这个问题IMO.
面向存储的选项的另一个变体是高可用的VM。你可以在Azure上启动自己的虚拟机，将数据驱动器备份到Azure Drives，然后使用操作系统上的一些东西(数据库服务器、直接使用文件系统的应用程序，等等)来完成这项工作。这将更类似于你在家里做的事情，但会有相当不幸的权衡。。。您的整个云现在都依赖于这一个VM的可用性、成本、解决方案的可扩展性等等。如果您查看虚拟机，Splunk也是一个需要考虑的选项。
正如前面的一位评论者所提到的，您可以计算日志外的数据。但这可能不是超实时的。
服务总线是另一个需要考虑的选项。你可以通过SB为这些事件发送消息，并让消费者读取它们并发出"摘要"。SB堆栈有很好的文档记录。SB的另一个有趣元素是，您可能能够用100%的正确性来换取性能/规模/成本。根据你的目标，这对你来说可能是一个有价值的权衡。
Azure还公开了可能适合的队列。我承认我认为SB可能更适合，但如果你走上这条路，这两者都值得一看。
对不起，我没有灵丹妙药，但我希望这能有所帮助。
我建议您遵循.NET多层应用程序中描述的模式。这将帮助您分离面向客户端的Web角色和Worker角色，Worker角色将使用服务总线将数据存储到持久性介质(SQLServer/AAzure存储)。
此外，这是一个有效的扩展模型，因为您可以跨越web角色或工作人员角色的新实例，或者两者兼而有之。对于仪表板(取决于负载)，您可以定期缓存数据并从缓存中为其提供服务器。这将损害数据的准确性，但仍将提供一个易于缩放的选项。您甚至可以每1分钟使缓存失效一次，然后从持久性介质加载缓存以获得最新的值。
关于使用SQL Server或Azure存储，如果不需要像JOINS等关系功能，那么您完全可以使用Azure存储。