Может ли выключатель Полли иметь экспоненциальную длительность выключателя? - PullRequest
Новая
       81

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

2 голосов
/ 17 апреля 2019

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

Документация для пула соединений гласит:

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

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

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

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

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

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

1 Ответ

2 голосов
/ 18 апреля 2019

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

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

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

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

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

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

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

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

...