Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, itslave, Вы писали:

C>ОЧЕНЬ плохая идея. Пиковую нагрузку надо или сразу обрабатывать, или кидать ошибки вызывающей системе, чтобы она замедлилась и не создавала такой нагрузки.
Ну опять, с чего бы так? Ну вот более чем типичный сценарий в том же амазоне: появилась пиковая нагрузка, увеличилось кол-во сообщений в очереди, автоскейлинг бекенда настроен на это реагирует, начинает запускать дополнительные машины. Но ет все — время исчисляемое минутами(а то и десятками минут в случае с виндой и рантайм провижинингом). Но тем не менее машинки подымаются, очередь разгребается через некоторое время.

C>Ещё хуже.
C>Ну так плохих идей вообще очень много.
Ну раз ты сказал — то значит так и есть
Давай присвоим этой цитате номер
2:45 евангелие от сайберакса


C>И как мониторинг позволит справится с backlog'ом сообщений, который ещё и будет расти во время диагностики причин ошибки? Особенно, если система построена на гарантированной доставке.
Мониторинг уведомит кого надо. Например админа или там систему дизастер рекавери, которая начнет разворачивать бекенд в другом регионе.


C>Проблема в том, что если сообщения вызывают изменение чего-то, то при пропуске одного сообщения не очень понятно итоговое состояние.
Про ент сорсинг я писал выше.

C>Оба варианта ведут к другим проблемам. Отсутствие retry делает обработку best-effort'ом в лучшем случае. Таймаут вызовет мину замедленного действия, позволив отравленным сообщениям постепенно накопиться и потом разом всё убить.
Опять таки, все зависит от сценария и от бизнес контекста.

C>Они не решают основную проблему — отсутствие "backpressure". Отправляющая сообщения сторона не знает, что backend может прямо сейчас находится при смерти, и что неплохо бы начинать делать throttling входящих запросов.
Вот как раз очередь и делает этот самы тротлинг, о чем я писал выше

C>Производители себе не враги, и никакие серьёзные последствия для них не последуют.
Ну да, канешна. И конкуренции на рынке очередей нет вообще