有关如何配置 Azure Storage Library 重试策略的信息，可参阅 Gaurav Mantri 撰写的一篇不错的文章。但很难找到关于使用何种重试策略设置的实用指导。本文章提供的建议是基于Microsoft 团队在高负载场景中使用SCL 的实际体验（对于低流量场景，使用默认的重试策略即可）。
ExponentialRetry与LinearRetry
对于不必考虑维持较短的响应时间的批处理， 类似乎是首选方法。您希望可以快速重试，以确保在最短的时间内清除瞬态错误，但您又不想给服务器带来过多压力，致使早已存在故障的服务产生更多的问题。而且，AzureStorage 团队正在不断调整策略，以使其具有更高的智能性，提供最佳的整体性能。
但是，想想这对您跟踪 Storage 服务连接质量的能力的影响。如果使用超时时间久且重试次数多的 ，您可以不必处理大多数瞬态错误的异常，但也不会知道其是否会频繁出现。您可以跟踪响应时间，但却不会知道其原因是否是瞬态错误。
一种解决方案是使用 ，其中包含客户端库在表层下执行的每个操作的结果。OperationContext 还提供端到端的跟踪，这有助于在分布式系统中诊断问题。如果需要收到关于重试的通知，可使用一个名为 的新事件。遗憾的是，目前还没有说明如何使用 OperationContext 的示例文档。
如果需要更多的诊断信息，还可以选择使用重试间隔短且重试次数少的 类，以便出现持久故障时更快速地发现。之后您可以一边报告故障，一边捕获异常并实施备用策略。请注意，如果希望大多数的请求最终成功，备用策略非常重要。
MaximumExecutionTime
接口还包括一个 属性。该值用于限制在所有重试上所花的总时间。根据您所执行的操作类型，该值可能需要比较大，因为大型操作需要一段时间才会出现故障。在要求大型操作的高负载条件下，我们发现，如果该值低于 10秒，将产生许多故障。将 MaximumExecutionTime 设置为 60 秒可避免异常。这种情况非常适合后台处理程序：对于面向客户的场景，您需要进行不同的调整。
我们发现， 和 值产生的影响不会很大。我们将其设置为 5 秒和 10 次重试，系统工作正常。而且，这是针对后台进程的优化，相对于快速响应时间，我们更关注最终的成功。此外，这种设置并不适用于所有的场景- 例如，如果您的应用程序正在下载 1TB 的 Blob，那么 5 秒的时间就不够长。如果不希望超时，也可以选择将 ServerTimeout 设置为 Null。从 StorageClient Library 4.0 开始，Null 将为默认值。
避免不必要的工作
对于某些操作，SCL API 提供了 IfExist 方法，可使用这种方法避免异常：示例:
foreach (IListBlobItem blobItem inthis.BlobList())
{
CloudBlockBlob cloudBlob = (CloudBlockBlob)blobItem;
cloudBlob.DeleteIfExists(options:this.requestOptions);
}
这看起来像是良好的防御性编程，事实也的确如此，不过这也增加了出现故障和增加流量的其他可能。在我们的压力测试中，这种方法经常会出现故障。如果知道存在某个项目，那么这种方法是没有必要的。更改代码以调用 而非 ，可以更好地执行操作，出现的故障也更少。因此，最好使用已知信息来减少流量和出现故障的可能性。
处理异常
即使是相对宽松的重试策略，有时候错误也会持续较长时间，从而产生异常。AzureStorage Client 框架可以有效地确保这些异常属于 或 System.。
此外，重试策略类不会重试 4xx 状态代码。也有一些其他状态代码（当前是 306、501 和 505）不会重试。这些代码表示该异常不属于瞬态错误, 因此需要您处理。常见示例为 404（未找到）和 409（冲突）。如果编写自定义重试策略，务必确保检查这些情况。
不必要的包装库
我们从 Azure Storage Client 开始，规划设计可以按照我们希望的方式执行重试的包装库。但结果表明这是没有必要的。我们仍着眼于编写业务逻辑库，将我们的重试调整和错误处理集中起来，但这些库要基于Azure Storage Client 代码。
感谢 Allen Prescott 执行此项测试并为本文章提供内容。
本文翻译自：