我可以在天蓝色函数中使用重试策略吗？答案

【问题标题】：Can I use a retry policy in an azure function?我可以在天蓝色函数中使用重试策略吗？
【发布时间】：2017-11-27 21:40:09
【问题描述】：

我正在使用事件中心来临时存储数据，这些数据将首先保存到 azure 表存储，然后索引到 elasticsearch。我在想我应该在天蓝色函数中进行存储保存调用，并为使用 NEST 的弹性搜索索引做同样的事情。处理数据很重要，所以我想我会使用 Polly 作为重试策略，以防弹性搜索服务器出现故障。但是，重试策略不会使 azure 函数变得昂贵吗？ azure 函数是正确的方法吗？

【问题讨论】：

标签： azure azure-functions azure-eventhub

【解决方案1】：

是的，您可以在 Azure Functions 中使用 Polly 进行重试。一些进一步的考虑：

是的，您需要为重试时间付费。但鉴于您的 Elastic Search 已“基本正常”，偶尔重试的额外费用不应太高。
如果您也想重试保存到表存储，则必须自己编写使用 Polly 修饰的调用，而不是其他首选的输出绑定
确保检查写入顺序是否对您很重要，以及是否应该在开始写入 Elastic 之前重试表存储写入完成，反之亦然。否则，您可以与async 和Task.WaitAll 并行执行它们
Function 的最长执行时间默认为 5 分钟，您可以配置最长为 10 分钟。如果您需要处理更长的中断，您可能需要一个计划 B。开始将失败超过 4（或 9）分钟的事件复制到专用队列，然后从那里重试。或在此类停机期间禁用该功能。

【讨论】：

我也想重试保存到表存储。使用两个单独的事件中心并在一个中处理索引并在另一个中保存表存储是否有意义？例如，一旦数据成功保存到表存储中，对象就会被传递到索引器事件中心。
如果您不要求这两个写入严格按照一个接一个的顺序发生，您可以为 same 事件中心设置两个使用者组：一个消费者写给表存储，一个写给 Elastic。这意味着两个 Azure Functions，每个使用者组一个。
它们不一定要以严格的顺序发生。一种可能的情况是存储失败而索引没有。然后数据将不同步。但是，也许我想多了 - 如果正确处理存储错误，它最终会被保存。也许最好的选择是使用两个消费者组和一个用于失败事件的专用队列。谢谢！

【解决方案2】：

是的。你可以使用一个库，或者最好只写一个简单的线性退避策略—— 比如尝试 5 次，中间休息 5 秒——然后做类似的事情

context.log.error({
    message: `Transient failure. This is Retry number ${retryCount}.`,
    errorCode: errorCodeFromCallingElasticSearch,
    errorDetails: moreContextMaybeSomeStack
});

每次您点击重试逻辑时，它都会转到 App Insights（确保您integrate with App Insights，否则您没有操作或完全是黑暗操作）。

然后，您可以查询真正错过的频率，并了解在 95% 的情况下情况如何。

偶尔在正常的 1 秒执行时间上运行 10 秒会产生额外费用，但可能远不及完整的专用应用服务计划。如果它接近，只需切换到那个，这意味着您的功能主要是打开而不是关闭 - 这仍然是运行功能的完美案例。

App Insights can also trigger alerts 如果某个指标出现问题，例如您的重试次数在 24 小时内达到 11 次，您可能想知道该偏差。您需要将重试计数作为自定义指标发送以触发警报：

context.log.metric("CallElasticSearchRetryCount", retryCount);

【讨论】：

感谢您的回答。我正在考虑使用单独的应用程序来处理事件，特别是因为它可能需要超过 10 分钟。我可以使用我现有的应用服务计划来托管我的网络应用。在定价方面，会不会有很大的不同？
请记住，您仍然可以使用专用计划中的功能。在这种情况下没有执行时间限制。