Azure Storage Client Library 重试策略建议

有关如何配置 Azure Storage Library
重试策略的信息，可参阅 Gaurav Mantri
撰写的一篇不错的文章《SCL
2.0 – 实施重试策略》。但很难找到关于使用何种重试策略设置的实用指导。本文章提供的建议是基于Microsoft
团队在高负载场景中使用SCL
的实际体验（对于低流量场景，使用默认的重试策略即可）。

ExponentialRetry与LinearRetry

对于不必考虑维持较短的响应时间的批处理，ExponentialRetry
类似乎是首选方法。您希望可以快速重试，以确保在最短的时间内清除瞬态错误，但您又不想给服务器带来过多压力，致使早已存在故障的服务产生更多的问题。而且，AzureStorage
团队正在不断调整策略，以使其具有更高的智能性，提供最佳的整体性能。

但是，想想这对您跟踪
Storage 服务连接质量的能力的影响。如果使用超时时间久且重试次数多的
ExponentialRetry，您可以不必处理大多数瞬态错误的异常，但也不会知道其是否会频繁出现。您可以跟踪响应时间，但却不会知道其原因是否是瞬态错误。

一种解决方案是使用
OperationContext.RequestResults，其中包含客户端库在表层下执行的每个操作的结果。OperationContext
还提供端到端的跟踪，这有助于在分布式系统中诊断问题。如果需要收到关于重试的通知，可使用一个名为
OperationContext.Retrying
的新事件。遗憾的是，目前还没有说明如何使用 OperationContext
的示例文档。

如果需要更多的诊断信息，还可以选择使用重试间隔短且重试次数少的 LinearRetry
类，以便出现持久故障时更快速地发现。之后您可以一边报告故障，一边捕获异常并实施备用策略。请注意，如果希望大多数的请求最终成功，备用策略非常重要。

MaximumExecutionTime

IRequestOptions
接口还包括一个
MaximumExecutionTime
属性。该值用于限制在所有重试上所花的总时间。根据您所执行的操作类型，该值可能需要比较大，因为大型操作需要一段时间才会出现故障。在要求大型操作的高负载条件下，我们发现，如果该值低于
秒，将产生许多故障。将
MaximumExecutionTime 设置为 60
秒可避免异常。这种情况非常适合后台处理程序：对于面向客户的场景，您需要进行不同的调整。

我们发现，ServerTimeout
和
maximum numberof retries
值产生的影响不会很大。我们将其设置为 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);

}

这看起来像是良好的防御性编程，事实也的确如此，不过这也增加了出现故障和增加流量的其他可能。在我们的压力测试中，这种方法经常会出现故障。如果知道存在某个项目，那么这种方法是没有必要的。更改代码以调用
Delete
而非
DeleteIfExists，可以更好地执行操作，出现的故障也更少。因此，最好使用已知信息来减少流量和出现故障的可能性。

处理异常

即使是相对宽松的重试策略，有时候错误也会持续较长时间，从而产生异常。AzureStorage
Client 框架可以有效地确保这些异常属于
StorageException
或 System.AggregateException。

此外，重试策略类不会重试
4xx 状态代码。也有一些其他状态代码（当前是、501
和）不会重试。这些代码表示该异常不属于瞬态错误,
因此需要您处理。常见示例为（未找到）和（冲突）。如果编写自定义重试策略，务必确保检查这些情况。

不必要的包装库

我们从
Azure Storage Client 开始，规划设计可以按照我们希望的方式执行重试的包装库。但结果表明这是没有必要的。我们仍着眼于编写业务逻辑库，将我们的重试调整和错误处理集中起来，但这些库要基于Azure
Storage Client 代码。

感谢
Allen Prescott 执行此项测试并为本文章提供内容。

本文翻译自：http://azure.microsoft.com/blog/2014/05/22/azure-storage-client-library-retry-policy-recommendations/