我看到一些线程说存储库已经有重试策略，那么我们为什么要使用这个：瞬态故障处理块
任何人都可以向我展示一些有关如何正确使用此瞬态故障处理块进行 myy blob 和表存储的示例吗？谢谢！
问问题
734 次
4 回答
1
有关实施示例，请继续阅读您发送的链接 - 关键场景部分。如果您没有连接问题，请不要实施。我们使用它，但据我们所知，它并没有帮助。我们遇到的每一个故障都是长期的，与 Azure 内部网络相关的问题，导致 TFHB 无法处理的故障。
于 2013-05-03T03:50:29.420 回答
1
One reason (and the reason I use it in my application) is that the transient fault handling application block provides retry logic for not only storage (tables, blobs and queues) but also for SQL Azure as well as Service Bus Queues. If your project makes use of these additional resources (namely SQL Azure and Service Bus Queues) and you would want to have a single library to handle transient faults, I would recommend using this over storage client library.
Another reason I would give for using this library is it's extensibility. You could probably extend this library to handle other error scenarios (not covered by storage client library retry policies) or use it against other web resources like service management API.
If you're just using blob and table storage, you could very well use the retry policies which come with storage client library.
于 2013-05-03T10:52:05.127 回答
0
我不将瞬态故障处理块用于 blob 存储，它可能更适用于表存储或传输更大的数据块时。鉴于我使用 blob 存储容器来存档站点某些区域的调试信息（以短 txt 文件的形式），这似乎有点令人费解。我从来没有目睹过任何写入存储的失败，我们每周写入成千上万的日志。当然，不同的存储使用可能会产生不同的可靠性。
于 2013-05-03T08:52:29.653 回答
0
对于表和 blob，您不需要使用任何外部瞬态重试块 afaik。在 sdk 中实现的那些相当健壮。如果你认为你应该实现一个特殊的重试策略，方法是实现你自己的从 Azure 存储接口继承的重试策略，并将其作为属性IRetryPolicy的一部分传递给你的存储请求。TableRequestOptions.RetryPolicy
于 2017-03-28T20:46:26.150 回答