C# 如何在从Azure表存储中删除批时避免404

问题

我试图从表存储中删除很多可能存在或不存在的行。交易是我需要最小化I/O和最大化带宽，所以一次点击就可以将它们统统掌控。问题是，如果任何批处理实体不存在，整个批处理就会失败

为什么

这也给我带来了一个设计问题——为什么请求不简单地返回一个删除结果，并指出哪些对象由于404而没有被删除。为什么会抛出异常？原因是什么

更多信息

---

批大小在表存储限制100范围内，并且它们都在同一分区内。

要回答您的问题，无法避免这种情况。如果批次中的一个实体失败，则整个批次将失败

但是，您可以做一件事：

当批处理失败时，它返回失败实体的索引。你所能做的就是将该批次从中创建3个单独的批次。第一批将从第一个实体（第0个索引）到失败实体的索引（减1），第二批将是失败实体（因此只有一个实体），最后一批将从失败实体索引到最后一个实体。对于失败的实体，您只需尝试

DeleteIfExists

。因此，假设一个批次中有100个实体，假设第30个实体失败，您将创建3个批次：

第1批：第0至29个实体（索引0-28）

第2批：第30个实体（单个实体）（索引29）

第3批：第31至100个实体（索引30-99）

这也给我带来了一个设计问题——为什么请求不 只需返回一个删除结果，并指示删除了哪些对象 由于404而未删除。为什么会抛出异常？问题是什么 原因

---

我可能想到的一个原因是存储API遵守REST。您试图删除一个资源，但它不在那里，所以API会抛出错误。此外，实体可能无法删除，这不仅是因为实体不存在，还因为请求中指定的

if match

条件标头不匹配。要详细说明，您可能只希望在

eTag

匹配时删除实体。在这种情况下，即使实体存在，删除操作也会失败。为了处理单个实体删除操作中的404错误，所有客户端SDK都实现了将消除404错误的

DeleteIfExists

类功能。

在删除之前，可以将具有相同PartitionKey和EntityKey的空实体放入。这样，您将确保不会出现404错误。每个批处理都有两个一致的调用，而不是多次重试，从而使应用程序的逻辑复杂化。这不是一个理想的答案，但我们并不是生活在一个理想的世界里：）

谢谢您的回复。听起来不那么糟糕。如果要删除N个实体，那么最坏的情况是会有O（N）个请求——这不是理想的。只有当批处理中有多个元素时，错误消息才会以失败元素的索引作为前缀！如下所示：

1:指定的资源不存在。

恒定数量的调用-我喜欢！此解决方案的唯一问题是，一个实体在批处理中只能出现一次。因此，您不能在单个批处理事务中创建和删除同一实体。没关系，有两个批处理事务：）我认为这不是一个好主意。在删除之前进行插入只是为了确保删除不会失败，这不是一个好的设计。基本上，插入记录是一种网络调用，可能会失败。此外，即使在执行此操作后，删除操作也可能因多种原因而失败，在这种情况下，您的实体数据已损坏。我的2美分：）