这个问题是针对经验丰富的建筑师的 - 大男孩是如何做到的？ :)
概述
我正在构建这个基于 .NET 的高流量、类似分析的解决方案，它最终将托管在 Azure 上。假设这个 Web 应用程序每天将收到超过 5 亿个“交易”，这些对我们的服务器的点击非常快，每个交易只需要很少的数据库查询，几乎所有繁重的工作都将在服务器端按设定的时间间隔完成。我非常确定我必须实现某种队列来存储所有传入的命中，并在后端实现“聚合器”，该聚合器每分钟左右运行一次以处理队列中的新项目。
建议的解决方案
如果我错了，请纠正我，但我认为将这些事务直接写入数据库(某种日志表)将是一个错误，因此我将利用 Azure 存储帐户(表)进行队列和旋转几个 Azure 辅助角色(根据需要)来处理数据并更新数据库。想法？
请务必记住，Azure 存储主要基于每次交易模型，因此我必须为所有传入交易(写入)以及聚合器的交易(读取)付费。因此每天 5 亿写入和 5 亿读取，结果约为 100 美元/天。那有意义吗？另外，通过使用 Azure 存储，我可以读取一组行(以说明单个事务)，还是必须一次读取队列中的一条记录？
最后，为每一行执行数据库插入/更新对于我的聚合器来说是一种过度杀伤力，因此我认为每个聚合器都应该聚合内存中的工作负载，然后将其清除到数据库。
最佳答案
我同意更新存储中的分析数据的请求应该通过放入队列的消息来完成，以便工作角色可以在后台处理这些消息，而不会影响实时用户。您甚至可以使用 AzureWatch @ http://www.paraleap.com 之类的工具根据队列中的数据量自动扩展服务器。
我强烈建议您考虑以下事实:每个队列每秒最多可以支持 500 个事务。如果您需要更多，请考虑托管多个队列并为您的队列提供一个模式(可能就像拥有可以随机连接到的 X 个队列一样简单:“Queue001..Queue100”。工作角色将检查所有 100 个队列，而您的网络服务器将生成 1 到 100 之间的随机数并连接到该队列
交易量实际上可能要大得多: 您的服务每天 5 亿次点击可能意味着:
- 500M 写入队列
- 从队列中读取 500M
- n * 500M 写入存储(其中 n 可能是倍数，如果您的存储结构 要求你在写出来之前先阅读内容，允许 批量交易等)
- x * 24*60*60/delay 检查队列以查看是否存在新消息(x 是队列数，delay 是每次检查之间的延迟(以秒为单位))
现在，如果您希望最大程度地减少队列的写入/读取量，请考虑缓冲从 Web 服务器到队列的请求，以便不是每个数据点都作为单独的消息发送，而是批量发送。这将限制对也算作事务(读取和写入)的队列的命中。您可以在网站中使用带有静态变量的锁来捕获点击，以便所有内容都存储在内存中，然后偶尔刷新到队列
如果您希望最大程度地减少针对表存储的存储事务量，请考虑使用本地存储来预聚合数据(如果可能)，并且仅将预聚合数据同步到表存储。这可能会有所帮助
每当我们缓冲数据写入时，假设如果带有缓冲数据的机器由于某种原因发生故障并且缓冲区尚未刷新，则可能会丢失一些数据。由于我们在这里不处理货币交易，我假设您对数据丢失的容忍程度略大于 0，并且通过写入缓冲节省的成本抵消了潜在的罕见数据丢失
HTH
关于architecture - Azure 上的高流量、每天超过 5 亿次点击(类似分析)的应用程序架构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14820290/