为什么我们需要瞬态故障处理来存储？答案

【问题标题】：Why we need Transient Fault Handling for storage?为什么我们需要瞬态故障处理来存储？
【发布时间】：2013-05-03 02:56:51
【问题描述】：

我看到一些线程说存储库已经有重试策略，那么我们为什么要使用这个：Transient Fault Handling block

谁能告诉我一些关于如何正确使用这个瞬态故障处理块来存储我的 blob 和表的示例？谢谢！

【问题讨论】：

标签： azure

【解决方案1】：

有关实施示例，请继续阅读您发送的链接 - 关键场景部分。如果您没有连接问题，请不要实施。我们使用它，但据我们所知，它并没有帮助。我们遇到的每一个故障都是长期的，与 Azure 内部网络相关的问题，导致 TFHB 无法处理。

【讨论】：

【解决方案2】：

一个原因（也是我在我的应用程序中使用它的原因）是瞬态故障处理应用程序块不仅为存储（表、blob 和队列）提供重试逻辑，还为 SQL Azure 和服务总线队列提供重试逻辑。如果您的项目使用这些额外的资源（即 SQL Azure 和服务总线队列），并且您希望有一个库来处理瞬态故障，我建议使用这个 over storage 客户端库。

我使用这个库的另一个原因是它的可扩展性。您可以扩展此库以处理其他错误场景（存储客户端库重试策略未涵盖）或将其用于其他 Web 资源，如服务管理 API。

如果您只是使用 blob 和表存储，则可以很好地使用存储客户端库附带的重试策略。

【讨论】：

【解决方案3】：

我不使用瞬态故障处理块进行 blob 存储，它可能更适用于表存储或传输更大的数据块时。鉴于我使用 blob 存储容器来归档站点某些区域的调试信息（以短 txt 文件的形式），这似乎有点令人费解。我从来没有目睹过任何写入存储的失败，我们每周写入成千上万的日志。当然，不同的存储用途可能会产生不同的可靠性。

【讨论】：

【解决方案4】：

对于表和 blob，您不需要使用任何外部瞬态重试块 afaik。在 sdk 中实现的那些相当健壮。如果您认为应该实施特殊的重试策略，方法是实施您自己的从 Azure Storage IRetryPolicy 接口继承的重试策略，并将其作为 TableRequestOptions.RetryPolicy 属性的一部分传递给您的存储请求。

【讨论】：