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

C>>Почитай SLA на сервисы Амазона или аналогичных. Никто ничего компенсировать не будет.
I>Я — читал. У тебя со чтением проблемы, как мы выяснили в соседнем треде. Да, живых денег не дают, просто ресурсы нахаляву, что напрямую трансформируется в деньги.
Ага. Ну вот смотрим SQS SLA. Упс. А его нету.

Ну ладно, смотрим EC2: https://aws.amazon.com/ru/ec2/sla/ — аж 30% скидки на целый МЕСЯЦ (!!!) в случае доступности менее чем в 99% (простой в 7 часов). Зверские, по-настоящему зверские, санкции.

Я видел соглашения со всякими Tibco и Oracle, и там всё примерно аналогично. В случае, если упадёт система сообщений, на которой висит весь бизнес организации, они дадут покупателям конфетку и воздушный шарик для компенсации возможно многомиллионных убытков.

C>>Ну и вообще, как можно проектировать системы, которые по дизайну будут требовать ручного привода???
I>Ты не понимаешь задачи и возможности мониторинга. Вообще.
Я в недоумении оглянулся на систему мониторинга, которую я написал и которая следит более за тысячами показателей в каждом из 19 регионов, которые мы поддерживаем.

Чем мониторинг должен помочь?

C>>Ну вот объясни. Требования я привёл.
I>Если то что ты привел — это требования, то не тебя жаль. Вот так навскидку и не читая реальных требований, я бы начал бороться с дубликатами и резким ростом нагрузки еще на client-side и тупо бы не отправлял бы эти дубликаты(там как раз их вычислить — плевое дело).
Ты понимаешь такое понятие — "очередь сообщений"? Туда запихиваются сообщения. Клиент не читает очередь, он туда пишет. Максимум очереди могут дедуплицировать сообщения по уникальному ID.

Но в данном случае это не поможет, так как при замедлении обработчика, он не будет справляться с нормальным потоком сообщений, которые вполне себе уникальны.

I>Там же имитировал бы circute breaker/increase timeouts в случаях если что-то пошло не так. Ну вот так навскидку, повторяюсь, исходя из того минимума что я знаю.
То есть? Я не понимаю что это значит в данном контексте. Очередь сообщений ни к каким таймаутам непричастна, сообщения туда штатно кладутся с обычной задержкой.

C>>Ну вот я и говорю — сообщения пригодны для fire-and-forget best effort вещей.
I>Нет. Очереди пригодны fire-ensure in delivery-and forget вещей. Сервис басы пригодны для более широких применений.
Если нужна гарантированная доставка, то я могу почти на 100% сказать, что сообщения используются неправильно.

C>>Ну вот сообщения не пригодны даже для молотка.
I>Ты сейчас говоришь, что асинхронная модель программирования в распределенной системе не пригодна ни на что.
Нет. Я говорю о том, что полностью пролетала распределённая модель, в которой часть состояния хранится в виде сообщений (т.е. потому и требуется гарантированная доставка).

Сами по себе асинхронные системы вполне себе нормально живут. Но даже там их лучше применять только для некритичных по времени вещей.

C>>Да, именно так я и считаю. И сколько раз уже на практике проверил.
I>Позволь спросить твой текущий тайтл. Просто интересно, насколько адекватный ресурс манагмент в амазоне.
Principal engineer.