Azure Storage Client Library 重试策略建议


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

ExponentialRetry 与 LinearRetry

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

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

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

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

MaximumExecutionTime

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

我们发现,ServerTimeoutmaximum number of retries 值产生的影响不会很大。我们将其设置为 5 秒和 10 次重试,系统工作正常。而且,这是针对后台进程的优化,相对于快速响应时间,我们更关注最终的成功。此外,这种设置并不适用于所有的场景 – 例如,如果您的应用程序正在下载 1TB 的 Blob,那么 5 秒的时间就不够长。如果不希望超时,也可以选择将 ServerTimeout 设置为 Null。从 StorageClient Library 4.0 开始,Null 将为默认值。

避免不必要的工作对于某些操作,SCL API 提供了 IfExist 方法,可使用这种方法避免异常:示例:

foreach (IListBlobItem blobItem in
this.BlobList())

{

   
CloudBlockBlob cloudBlob = (CloudBlockBlob)blobItem;

cloudBlob.DeleteIfExists(options:this.requestOptions);

}

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

处理异常

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

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

不必要的包装库

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

 

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

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

 

Comments (0)

Skip to main content