Может ли автоматический выключатель Polly иметь экспоненциальную продолжительность прерывания?

Мы пытаемся реализовать политику повтора для нашей логики базы данных, когда получаем исключения из-за истечения времени ожидания из-за исчерпания пула соединений. Это происходит, когда у нас наблюдается всплеск необычно большой активности в течение небольшого периода времени. Мы увеличили максимальный размер пула, чтобы избежать этой ситуации, но мы также хотели бы иметь логику повтора в качестве плана резервного копирования.

Документация по пулу соединений заявляет, что:

Когда пул подключений включен, и если возникает ошибка тайм-аута или другая ошибка входа в систему, будет создано исключение, и последующие попытки подключения завершатся неудачно в течение следующих пяти секунд, «периода блокировки». Если приложение пытается подключиться в течение периода блокировки, первое исключение будет сгенерировано снова. Последующие сбои по окончании периода блокировки приведут к появлению новых периодов блокировки, которые вдвое превышают продолжительность предыдущего периода блокировки, но не более одной минуты.

Полли, по-видимому, хорошо подходит для решения этой проблемы с помощью комбинации политик PolicyWrap, включающей в себя Fallback, WaitAndRetry и Circuit Breaker. Хорошая фотография этого здесь

В идеале я надеялся, что смогу указать экспоненциальную длительность прерывания для прерывателя цепи, чтобы она соответствовала периоду удвоения, описанному выше. Я не видел в Интернете примеров того, как это могло быть возможно, так что, может быть, это невозможно?

Какой здесь подход к конфигурации? Следует ли указать прерыватель цепи с 5-секундной продолжительностьюOfBreak, а затем использовать экспоненциальную повторную попытку для компонента WaitAndRetry в 5, 10, 20, 40 и 60 секунд? Это кажется неудачным в том случае, если соединения только что стали доступны, и ваша старая операция только что начала свое 40-секундное ожидание, в то время как новая операция будет работать немедленно.

Другая возможность - иметь 5-секундную durationOfBreak, а затем заставить компонент WaitAndRetry использовать очень маленькое ожидание с большим количеством повторных попыток, хотя мы знаем, что многие из этих повторных попыток завершатся неудачно, если они будут выполнены до того, как указано в документации.

Я ценю ваш отзыв!


person Mark Brown    schedule 17.04.2019    source источник


Ответы (1)


Polly не предлагает автоматические выключатели с переменной (например, экспоненциальной) продолжительностью отключения.

Следующее может сначала показаться нелогичным, но: Звучит так, как будто эта ситуация не требует автоматического выключателя с экспоненциальным откатом, потому что описанный алгоритм пула соединений ADO.NET уже эффективно работает. при условии что.

Обоснование: Назначение автоматического выключателя состоит в том, чтобы прекратить передавать вызовы в систему ниже по потоку, которая вряд ли справится с ними, чтобы: (а) быстро выйти из строя для вызывающего абонента; (б) защитить базовую систему от чрезмерной нагрузки. Похоже, что алгоритм ADO.NET уже выполняет обе эти цели.

Точно так же цель политики повторных попыток экспоненциального отката состоит в том, чтобы не допустить, чтобы повторные попытки сами по себе «умножали» нагрузку (создавая самоиндуцированную DDOS-атаку на базовую систему ... поступает больше запросов, и существующие запросы также повторяются). Опять же, похоже, что алгоритм ADO.NET force-you-to-back-off применяет свой собственный экспоненциальный откат для защиты базового БД, поэтому (*) может не быть никакой пользы от наслоения вашей собственной экспоненциальной обратной связи Polly - вдобавок ко всему.

Поскольку ADO.NET обеспечивает собственную защиту, у меня возникнет соблазн сделать что-нибудь простое, например, использовать политику повторных попыток с фиксированным интервалом повторных попыток в 5 секунд или 5 с небольшим секунд. (Какой бы «период блокировки» ни действовал, кажется, он будет кратен 5 секундам.)

Это предложение основано на предположении, что управление пулом соединений ADO.NET (в отношении этого периода блокировки) происходит на стороне вызывающего абонента; то есть код ADO.NET, встроенный в вызывающее приложение, решает, что его пул соединений полностью использован, и отклоняет дальнейшие попытки соединения в период блокировки , не передавая сетевой вызов базовому серверу SQL для проверки. Если это предположение неверно, то приведенный выше совет (*) может быть неверным, и вам было бы лучше использовать экспоненциальную политику повторных попыток отката, чтобы избежать перегрузки сервера базы данных при повторных попытках подключения.


Предупреждение: я не работал напрямую с этим конкретным ограничением ADO.NET. Те, у кого есть, могли бы дать лучший совет. Те, кто лучше знает внутреннюю архитектуру ADO.NET, возможно, лучше знают, насколько «дорого» делать попытки каждые пять секунд (как я предположил), которые могут быть отклонены.


Дополнение. В этом обсуждении также игнорируются любые аспекты высокой параллельной нагрузки в вызывающей стороне, вызывающей нехватку потоков / ЦП и т. д. Если это вопрос, подумайте о упреждающее снижение нагрузки на известном допустимом пределе.

person mountain traveller    schedule 17.04.2019
comment
Я ценю ваши предложения, а также ваши честные предостережения. :) Если я правильно следую, я думаю, вы предполагаете, что мне не нужен автоматический выключатель - просто используйте политику повторных попыток и позвольте ADO.NET обработать его часть автоматического выключателя. Это кажется хорошим советом. Я подожду, чтобы увидеть, ответит ли кто-нибудь еще, а затем поставлю вам высокую оценку за правильный ответ. - person Mark Brown; 18.04.2019