Azure Storage Client Library 重试策略建议

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/


上一篇:【CF884F】Anti-Palindromize 费用流


下一篇:纯css3实现的3D按钮