我的应用程序使用的是 Windows azure 和 SQL 数据库（Azure）。在不久的将来，我们的 SQL 数据库的流量将接近 50,000 个事务/分钟。我正在使用 5GB 的 Web 数据库。
现在 SQL 数据库中每个分区有 400 个并发操作的限制：参考
有哪些可能的方法来克服这个限制？目前我能想到的最好的解决方案是联邦。还有哪些其他方式？哪一个是最好的？
编辑：事务将只写。我们每 5 秒从客户端系统收集性能数据，这些数据被发送到我们的 REST API，最终将数据插入 SQL 数据库。所以没有 UI 和缓存是不可能的。
在 Windows Azure SQL 数据库中使用联合是一种选择。但我更喜欢将繁重的工作卸载到不同的数据存储，如表存储、Blob 或队列，因为它们是为处理繁重的负载而构建的，并且它们更容易分区。将此与良好的缓存相结合，您可能会轻松克服此限制。
想象一下，您的网站在您的主页上有前 10 种产品列表，并且您每天有 100,000 名访问者。一种选择是每次都查询 SQL Azure，但这可能会导致 SQL Azure 负载过重。但是您可以让工作进程每 24 小时运行一次并计算当时排名前 10 的产品，并将它们保存在表存储中（您可以在该表中创建一些分区，其中包含每个国家、每个类别的前 10 个产品，. ..)。您可以将其视为预先生成的视图。每次您想要显示前 10 名产品时，您都会从可扩展性更好的表存储（表中的特定分区）中查询项目。在那里添加一些 ASP.NET 缓存，您将拥有一个非常可靠的系统。
那就是读取数据。但我想你也会期待一些用户输入，用户可以在其中创建订单、发送消息……再说一次，如果你期望负载很重，SQL Azure 可能不是直接与之交互的最佳选择（见限制）。在前端和后端之间使用队列可能是更好的解决方案。
当您的用户下订单时，您可以将消息写入队列（存储队列或服务总线队列）。工作人员将接收此消息，并在表格中为该订单创建一条记录，其中包含时间、产品数量，甚至可能是您将在用户订单屏幕中显示的状态（如处理中）。完成此操作后，您就有了完成订单所需的所有时间，完成后您将最终结果保存在 SQL Azure 中（并更新表存储中的订单记录）。将最终结果保存在 SQL Azure 中仍然可以使用报告等...
这将对您的应用程序产生很大影响。另一种解决方案是自己在虚拟机中托管 SQL Server，但请注意，这仍在 CTP 中：Provisioning a SQL Server Virtual Machine on Windows Azure
联邦当然是一种选择，因为它是一个无共享的基础设施。但是，您可能需要首先思考为什么需要如此大量的交易。您的事务将主要是读取还是写入操作？你有中间层吗？可用于写入和读取操作的技术不同。当您有一个中间层时，您可以使用以下一些技术来帮助您最大限度地减少 SQL 数据库实例上的每秒事务数：
当您的系统在读取场景（或非规范化）中尝试向消费者提供数据时，缓存非常重要。除了说您有严重的利弊需要考虑之外，我不会扩展缓存，例如数据新鲜度和跨节点的同步问题。下面的其他两种技术用于写入。
基于集合的事务在数据库系统中绝对是至关重要的。例如，如果您的系统每秒插入大量记录，您可以将插入请求放入队列中，然后在单独的线程上处理队列，然后将十或二十个请求汇集到单个数据库调用中。这需要对数据库进行异步处理和基于集合的操作。但归根结底，对记录进行分组处理是 SQL 数据库成功的关键之一。如果不是为了实现类似的模式，我们现在正在设计一个每秒可以处理超过 500 个事务的系统。
最终一致性是另一个重要的概念，我之前在基于集合的方法中提到过它。最终一致性意味着数据库现在可能不包含所有记录，并且可能需要一些时间才能使所有记录可用。但最终，记录会成功。我上面提供的示例（带有队列）实现了基于集合的操作和最终一致性模式。