Здравствуйте, itslave, Вы писали:
C>>Во-первых, на системах сообщений совершенно нельзя делать протоколы вида вопрос-ответ. Любые попытки такого приведут в АДЪ из-за сложности. I>Можно и делают. Ессна ж ни разу не силвер баллет, но диапазон применимости достаточно широк.
Я видел даже реализации аналогов TCP на сообщениях, с flow control и прочим. Это не значит, что это хорошая идея.
Пока я для себя нашёл два нормальных применения очередей:
1) Раскидывание вычислений или длинных асинхронных задач по вычислительному кластеру.
2) Простые best effort fire-and-forget пинги для внешних систем с уведомлениями об изменениях.
C>>Если по каким-то причинам шаг Б начинает тормозить, то мы можем получить ряд интересных вариантов развития событий. Очередь начнёт расти неограниченно, при этом в зависимости от политики очереди новые сообщения могут вообще не обработаться (если FIFO и есть таймаут). I>Нормальные очереди дизайнят так, чтобы они были I> — безразмерными I> — не тормознутыми I> — гарантировали высокий SLA по авайлабилити
Прочитай то, что я написал. Ломается не очередь, а обработчик, из-за чего глубина очереди начинает расти. При этом именно система сообщений может прекрасно работать. И потом особенно смешно бывает, если сообщения в глубине очереди уже не могут быть обработаны из-за того, что связанные с ними объекты перестали быть актуальными.
I>При таких вводных, вероятность описанного сценария минимальна(а все в распределенных системах упирается в вероятности в конечном итоге), зато позволяет тротлить нагрузку на бекенд и мониторить логически развязать фронтенд и бекенд(что помимо всего прочего, позволяет делать 0-downtime update для бекенда).
Это всё ещё лучше делается и без систем сообщений. А на слово "decoupling" я нынче вообще сразу бью в рожу.
C>>В-третьих, вопрос надёжности — если сообщение из очереди ошибочно удалено, то очень сложно разобраться что там вообще произошло. I>Вопрос исключительно к мониторингу и агрегации логов.
У меня их терабайт в час на некоторых системах. Но речь не об этом, проблема в том, что если сообщение удалено, то во многих системах на сообщениях ничерта не понятно в каком состоянии стала находится система. Была ли сделана задача, связанная с сообщением?
C>>В-четвёртых, появляется шаблон отказа — "отравленное сообщение". 1. При обработке сообщения случается ошибка и система его кладёт обратно в очередь. Далее goto 1. Если таких сообщений несколько десятков, то они спокойно забивают остальной трафик. I>Как я уже отметил выше — retries + dlq лечит такие варианты. Хотя перфоманс может деградировать, если ретраев больше нуля(те не слать месседж в dlq при первой же ошибке).
Опять же, читай что я написал. Имеется отравленное сообщение, которое вызывает ошибку при обработке (ну вот бага в коде обработчика). Так как это сообщение не подтверждается, то очередь очень услужливо делает ему retry, снова завершающийся ошибкой.
Если retry'ев много, то отравленные сообщения вытеснят все остальные, даже если скорость их поступления незначительная.
DLQ тут вообще непричём, разве что только для аутопсии после того, как всё сломается.
C>>Ну и система сообщений — это единая точка отказа, неплохо бы такие вещи минимизировать. I>Все упирается в SLA. Зачастую очереди — распределенные системы, с SLA выше чем у поставщиков-потребителей этой очереди.
Ой, ну не надо. Производители могут дать SLA в 146%, только ведь всё равно всё упадёт.
