2

关于将 RetryPolicy 与表存储结合使用的几个问题，

  1. 尽可能使用 RetryPolicy 是否是最佳实践，因此尽可能使用 ctx.SaveChangeWithRetries() 而不是 ctx.SaveChanges() ？

  2. 例如，当您使用 RetryPolicy 时，

    ctx.RetryPolicy = RetryPolicies.Retry(5, TimeSpan.FromSeconds(1));

人们通常对 retryCount 和 TimeSpan 使用什么值？我看到 5 次重试和 1 秒 TimeSpan 是一个流行的选择，但是每次 1 秒重试 5 次会不会太长？

谢谢，

射线。

4

2 回答 2

2

我认为这在很大程度上取决于您的应用程序和要求。ATS 的超时错误很少发生，如果重试策略不会受到影响，并且无论如何也很少使用。但是，如果发生了一些可疑的事情，它可能会使您不必调试奇怪的错误。

现在，我建议您在开始时根本不启用 RetryPolicy，而是进行跟踪，以便您可以看到任何与 ATS 持久性有关的问题。稳定后，放置 RetryPolicy 可能是解决 ATS 端的一些运行时故障的好主意。只要确保你没有用 RetryPolicy 掩盖你自己的问题。

于 2010-12-28T17:54:21.260 回答
1

如果您的客户端像网页一样面向用户，您可能希望在每次重试之间使用带有短等待（毫秒）的线性重试，如果您的客户端实际上是非面向用户的后端服务等，那么您很可能想要使用指数重试以避免表存储服务过载，以防它已经由于高负载而出现 5xx 错误。

使用最新的 Azure 存储客户端 SDK，如果您未通过 TableRequestOptions 在表请求中定义任何重试策略，则使用默认重试策略，即指数重试。sdk 对它认为可重试的错误总共重试 3 次，如果所有重试都失败，这总共需要或多或少 20 秒。

于 2016-03-10T17:39:24.573 回答