Здравствуйте, Shmj, Вы писали:
S>Но вот как лучше делать повторы на практике? Можно ли придумать некое универсальное настраиваемое решение? Что используете вы?
Такие решения давно придуманы. Полиси ретраев (количество и периодичность) в нормальных библиотеках выделены в отдельный классы (или функции). В библиотеке есть готовые классы — для постоянного времени между ретраями, для экспоненциального, и т.п. При желании — можно легко написать свой класс для кастомной логики. Open-closed Principe в действии
Мы используется экспоненциальный, до некоторого периода. Потом сбой, или постоянные редкие ретраи. Плюс джиттер
Здравствуйте, Sinclair, Вы писали: S>Вот мне, кстати, всегда было непонятно, почему нужно именно экспоненциальное время задержки. Почему не арктангенс или кусочно-линейное? Ну, типа попробовали ежеминутно-через 5 минут — через полчаса — через час — и долбим раз в час.
Конкретные сценарии и ограничение сверху зависят от системы. А цель — избежать того, что называется "dogpile" — различия в нагрузках на различных этапах (например, при старте сервера и в процессе нормальной работы). (Я сейчас по Release It, second edition, pp. 78-80 привожу).
Допустим, сервис А вызывает сервис Б. В какой-то момент сервис Б не выдержал нагрузки и ушел в дикие задержки. Некоторые экземпляры упали, некоторые нет. Часа через три проснулись разработчики и операторы сервиса Б и попробовали его починить. Только есть проблема — ваш сервис А к этому моменту дает четырехкратную нагрузку на сервис Б! Четырехктратная — это обычная нагрузка плюс повторы операций за три часа, которые сервис лежал. При этом при старте сервис может требовать больше ресурсов — кэши не заполнены, код не проджитен. Он уже при нормальной нагрузке упал, а тут — четырехкратная (и возрастающая, так как текущую нагрузку он облуживать еще не может).
Экспонента позволяет избежать такого "умножения" нагрузки. При этом активно используется и рандомизация — чтобы пришедшая за короткое время волна тоже размазывалась (в диапазоне, допускаемом "экспонентой"). Без рандомизации волна будет повторяться и может приводить к повторным отказам. А с рандомизацией она будет увеличиваться в длине но уменьшаться в высоте (при условии, что остальная нагрузка не пиковая).
Если у вас запросы раз в минуту — можно делать любое время задержки. А вот при сотнях-тысячах запросов в минуту все эти тонкости становятся уже важны. Они позволяют ограничить масштабы проблемы и в дальнейшем быстрее вернуться в рабочий режим. Если интересует тема надежности, рекомендую вышеупомянутую Release It — легко читается, содержит как примеры реальных отказов систем, так и практические советы о том, как избежать проблем.
Здравствуйте, Shmj, Вы писали:
S>Но вот как лучше делать повторы на практике? Можно ли придумать некое универсальное настраиваемое решение? Что используете вы?
А зачем универсальное? Неясно зачем для этого вообще некий супер-фреймворк с трёхэтажной конфигурацией? Функциональность тривиальная — дать задержку, повторить. Три строчки кода. Не нужен для этого фреймворк.
Самое сложное в этой задаче — изучить специфику сервиса — как он ведёт себя при падении, как быстро чинится и т.п. — на этом основании придумать собственно придумать функцию, выдающую задержки, чтобы система восстанавливалась как можно быстрее и требовала минимум ручного вмешательства. А это — никак не алгоритмизуется в общем случае.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Ну если хочется очень заморочиться, то можно собрать статистику, придумать таргет функцию и построить оптимальную логику ретрая под таргет функцию.
Если этот процесс сделать автоматическим, то получишь адаптивный механизм.
Только, имхо, для 99.99% задач это нафиг не нужно.
