Azure表存储RetryPolicy问题

关于在表存储中使用RetryPolicy的几个问题

最佳做法是尽可能使用RetryPolicy，因此尽可能使用ctx.SaveChangeWithRetries（）而不是ctx.SaveChanges（）

例如，当您使用RetryPolicy时

ctx.RetryPolicy=RetryPolicies.Retry（5，TimeSpan.FromSeconds（1））

人们通常对retryCount和TimeSpan使用什么值？我认为5次重试和1秒时间间隔是一个流行的选择，但是5次重试和1秒时间间隔是否会太长

谢谢,

---

Ray.

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

---

现在，我建议您在一开始根本不启用RetryPolicy，而是使用跟踪，这样您就可以看到任何与ATS的持久性相关的问题。一旦稳定下来，使用RetryPolicy解决ATS端的一些运行时故障可能是个好主意。只需确保您没有用RetryPolicy掩盖自己的问题。

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

使用最新的Azure Storage client SDK，如果未通过TableRequestOptions在表请求中定义任何重试策略，则将使用默认的重试策略，即指数重试。sdk对其认为可重试的错误总共重试3次，如果所有重试都失败，则总共需要20秒左右的时间