Управление поиском Azure 503
Есть ли известный шаблон для управления ServiceUnavailable? Я не так счастлив с чем-то вроде этого
catch (CloudException e) when (System.Net.HttpStatusCode.ServiceUnavailable.Equals(e.Response?.StatusCode))
{
var howMuchWait = TimeSpan.FromMinutes(1);
if (e.Response.Headers.TryGetValue("Retry-After", out var hValue))
{
if(RetryConditionHeaderValue.TryParse(hValue.FirstOrDefault(), out var time) && time.Delta.HasValue)
{
howMuchWait = time.Delta.Value;
}
}
logger.LogWarning(() => $"Service Unavailable... Let him rest a bit, I will wait for {howMuchWait}.");
await Task.Delay(howMuchWait);
return indexEntities.Select(x => (string)x[indexKeyFieldName]).ToList();
}
Этот код просто задерживает текущий вызов к нему, но не предотвращает вызовы из других потоков. Теперь я реализую что-то другое, используя Stopwatch
и я хотел бы знать, есть ли известный образец. ПРИМЕЧАНИЕ: все, используя SDK.
1 ответ
При управлении для 503-х годов лучше внедрить дополнительный механизм постепенного отката, а не фиксированную задержку по времени. Например, начните с 1 секунды, затем 2, затем 4, затем 8 и т. Д. Основная причина этого заключается в том, что если вы отправляете большую часть работы в Поиск Azure, лучше всего позволить ей наверстать упущенное, а не наоборот. чтобы постоянно пытаться отправить больше работы к нему.
Кстати, для тех, кто читает это, иногда вы можете подумать, что было бы неплохо добавить разделы, когда вы видите эти 503 (обычно для массовых загрузок), чтобы дать больше ресурсов, хотя на самом деле это может вызвать больше 503, как это больше работы, которую должен сделать сервис для настройки разделов. Если вы считаете, что вам нужно больше разделов, лучше сделать это до того, как вы начнете выполнять работу, а затем при необходимости уменьшить ее.
Еще одно замечание: если вы использовали SDK Azure Search.NET, повторная попытка уже встроена. Брюс, здесь есть немного полезной информации: Azure Search RetryPolicy