zoukankan      html  css  js  c++  java
  • Azure Storage Client Library 重试策略建议

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

    ExponentialRetryLinearRetry

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

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

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

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

    MaximumExecutionTime

    IRequestOptions 接口还包括一个 MaximumExecutionTime 属性。该值用于限制在所有重试上所花的总时间。根据您所执行的操作类型,该值可能需要比较大,因为大型操作需要一段时间才会出现故障。在要求大型操作的高负载条件下,我们发现,如果该值低于 10秒,将产生许多故障。将 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 状态代码。也有一些其他状态代码(当前是 306501 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/


    
  • 相关阅读:
    一个简单的knockout.js 和easyui的绑定
    knockoutjs + easyui.treegrid 可编辑的自定义绑定插件
    Knockout自定义绑定my97datepicker
    去除小数后多余的0
    Windows Azure Web Site (15) 取消Azure Web Site默认的IIS ARR
    Azure ARM (1) UI初探
    Azure Redis Cache (3) 创建和使用P级别的Redis Cache
    Windows Azure HandBook (7) 基于Azure Web App的企业官网改造
    Windows Azure Storage (23) 计算Azure VHD实际使用容量
    Windows Azure Virtual Network (11) 创建VNet-to-VNet的连接
  • 原文地址:https://www.cnblogs.com/new0801/p/6176256.html
Copyright © 2011-2022 走看看