如何在Azure中构建高度可扩展的全局计数器？

Question

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

感谢您的帮助/想法！

Answer 1

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

史蒂夫马克思还在博客文章中详细讨论了这个问题，其中包含源代码：Architecting Scalable Counters with Windows Azure。在这个解决方案中，他们正在做以下事情：

• 在每个实例上，跟踪本地计数器
• 使用Interlock.Increment修改本地计数器
• 如果计数器发生了变化，请将新值保存在表存储中（每隔几秒钟就有一个计时器）。对于每个部署/实例，您将在计数器表中有1条记录。
• 要显示总计数，请取计数器表中所有记录的总和。

Answer 2

嗯，有很多选择。我不知道哪个最适合你。但是我会在这里提出一些优点和缺点，你可以根据自己的要求得出自己的结论。

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

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

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

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

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

抱歉，我没有银弹，但我希望这有帮助。

Answer 3

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

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

关于使用SQL Server或Azure存储，如果不需要JOINS等关系功能，您可以很好地使用Azure存储。