1

我正在尝试在 Windows Azure 中设置一个全局计数器，该计数器将跟踪一天内开始的游戏数量。每次玩家开始游戏时，都会从客户端向服务器发出一个 Web 服务调用，并且全局计数器将加一。使用数据库应该相当简单......但我想知道如何有效地做到这一点。数据库方法同时适用于数百个客户，但如果我有 100,000 个客户会发生什么？

感谢您的帮助/想法！

4

3 回答 3

6

一年多前，这是 Cloud Cover 插曲中的一个主题：Cloud Cover Episode 43 - Scalable Counters with Windows Azure。他们讨论了如何创建Apaythy Button（类似于 Facebook 上的 Like Button）。

Steve Marx 还在包含源代码的博客文章中详细讨论了这一点：Architecting Scalable Counters with Windows Azure。在此解决方案中，他们正在执行以下操作：

  • 在每个实例上，跟踪本地计数器
  • 用于Interlock.Increment修改本地计数器
  • 如果计数器发生变化，请将新值保存在表存储中（让计时器每隔几秒执行一次）。对于每个部署/实例，您将在计数器表中拥有 1 条记录。
  • 要显示总计数，请计算 counters 表中所有记录的总和。
于 2012-11-27T08:03:31.273 回答
0

好吧，有很多选择。而且我不知道哪个最适合你。但是我会在这里介绍它们的一些优点和缺点，您可以根据您的要求得出自己的结论。

最简单的答案是“存放起来”。SQL Azure 和核心 Azure 表或博客存储选项都适合您。要解决的一个问题是面对大规模并发时的性能，但我也鼓励您考虑正确性。你真的想要支持原子增量的东西来外包这个问题 IMO。

面向存储的选项的另一种变体是高度可用的虚拟机。您可以在 Azure 上启动自己的 VM，将数据驱动器备份到 Azure 驱动器，然后使用操作系统之上的某些东西来执行此操作（数据库服务器、直接使用文件系统的应用程序等）。这将更类似于您在家中所做的事情，但会有相当不幸的权衡……您的整个云现在都依赖于这台虚拟机的可用性，成本是需要考虑的事情，解决方案的可扩展性，等等。如果您查看虚拟机，Splunk 也是一个可以考虑的选项。

正如之前的评论者所提到的，您可以根据日志数据进行计算。但这可能不是超实时的。

服务总线是另一个需要考虑的选项。您可以通过 SB 为这些事件发送消息，并让消费者读取它们并发出“摘要”。如果你看这个，有很多设计模式需要考虑。SB 堆栈有很好的文档记录。SB 的另一个有趣的元素是，您可能能够以 100% 的正确性来换取性能/规模/成本。根据您的目标，这对您来说可能是一个值得权衡的选择。

Azure 还公开了可能适合的队列。我承认我认为 SB 可能更合适，但如果你走这条路，两者都值得一看。

对不起，我没有灵丹妙药，但我希望这会有所帮助。

于 2012-11-27T06:26:12.743 回答
0

我建议您遵循.NET Multi-Tier Application中描述的模式。这将帮助您将面向客户端的 Web 角色和 Worker 角色分离，后者将使用服务总线将数据存储到持久性介质（SQL Server / Azure 存储）。

此外，这是一种有效的扩展模型，因为您可以跨越 Web 角色或辅助角色或两者的新实例。对于仪表板，取决于负载，您可以定期缓存数据并从缓存中提供服务。这会影响数据的准确性，但仍会提供易于扩展的选项。您甚至可以每 1 分钟使缓存无效，并从持久性介质中加载它以获取最新值。

关于使用 SQL Server 或 Azure 存储，如果不需要诸如此类的关系功能JOINS，您可以很好地选择 Azure 存储。

于 2012-11-27T06:46:45.017 回答