我需要在表存储中创建增量报告。我需要能够从几个不同的工作角色实例（每个角色有几个实例的不同角色）更新相同的记录。
我的报告主要包含在解析最初存储的原始数据后需要增加的值。
我找到的乐观解决方案是使用重试机制：尝试更新记录。如果您收到 412 结果代码（您没有最新的 ETAG 值），请重试。您拥有的用户越多，您需要同时更新的数据越多（我的情况正是如此），这种解决方案的效率和成本就会越来越低。
想到的另一种解决方案是只有一个工作者角色的一个实例可以更新任何给定的记录。这是非常有问题的，因为这意味着我将按设计在我的架构中创建瓶颈，这与我希望通过 Azure 达到的规模相反。
如果这里有人对这种用例有一些最佳实践，我很想听听。
大多数云存储（表存储就是其中之一）不提供对单个实体/blob/任何东西的可扩展写入。此限制没有快速解决方案，因为此限制来自首先创建云存储的核心权衡。
基本上，一个存储单元（实体/blob/whatever）可以大约每 20 毫秒更新一次，仅此而已。有没有专门的工人不会改变这方面的任何事情。
相反，您需要从不同的角度解决您的任务。对于计数器，最常用的方法是使用分片计数器（链接适用于 GAE，但您可以在 Azure 上实现等效行为）。
此外，另一种缓解异步架构 ala CQRS 带来的痛苦的方法，在这种架构中，您对实体更新延迟的性能限制得到了显着放松。
我相信这种方法需要重新架构。为了确保可扩展性和限制争用量，您希望通过提供唯一的 Table/PartitionKey/RowKey 来确保每次写入都可以乐观地工作
如果您需要将报告的这些值合并在一起，请有一个单独的流程/工作人员将后聚合/合并记录以用于报告目的。您可以使用队列或计时机制来开始聚合/合并