我需要在表存储中创建增量报告。我需要能够从几个不同的工作者角色实例（每个具有多个实例的不同角色）更新相同的记录。
我的报告主要包含在解析最初存储的原始数据后需要增量的值。
我找到的乐观解决方案是使用重试机制：尝试更新记录。如果您获得412结果代码（您没有最新的ETAG值），请重试。对于您拥有的用户越多，同时更新所需的数据越多（我的情况就是这样），此解决方案的效率和成本都会降低。
我想到的另一个解决方案是只有一个可以更新任何给定记录的辅助角色的实例。这是非常有问题的，因为这意味着我将通过设计在我的架构中创建瓶颈，这与我希望通过Azure达到的规模相反。
如果这里的任何人都有这样一个用例的最佳实践，我很乐意听到它。
答案 0 :(得分：2)
大多数云存储（表存储就是其中之一）不能在单个实体/ blob /上提供可扩展的写入。这种限制没有快速解决方案，因为这种限制来自于首先创建云存储的核心权衡。
基本上，存储单元（实体/ blob /无论如何）可以每20ms更新一次，就是这样。拥有一名专职工作者不会改变这方面的任何内容。
相反，您需要从不同的角度解决您的任务。对于计数器，最常用的方法是使用sharded counters（链接用于GAE，但您可以在Azure上实现等效行为）。
此外，另一种减轻异步架构ala CQRS的痛苦的方法，其中你对实体更新延迟的性能限制显着放松。
答案 1 :(得分：0)
我认为这种方法需要重新架构。为了确保可伸缩性并限制争用量，您希望通过提供唯一的Table / PartitionKey / RowKey来确保每个写入都能乐观地工作
如果您需要将报表的这些值合并在一起，请让一个单独的流程/工作人员将后期汇总/合并记录以用于报告目的。您可以使用队列或计时机制来启动聚合/合并