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

C>>Ага. Ну вот смотрим SQS SLA. Упс. А его нету.
I>А оно есть, хотя канечна аптайм они не гарантируют. Зато гарантируют доставку принятого сообщения:
Не гарантируют. В случае падений SQS сообщения ещё как теряются, хотя они в последнее время исправились и падать почти перестали.

I>А вот мелкософт дает полноценный sla на свой azure service bus.
Аж 25% скидки за последний месяц. Прямо как санкции против Северной Кореи по своей жестокости.

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

C>>Я видел соглашения со всякими Tibco и Oracle, и там всё примерно аналогично. В случае, если упадёт система сообщений, на которой висит весь бизнес организации, они дадут покупателям конфетку и воздушный шарик для компенсации возможно многомиллионных убытков.
I>А с чего ты взял что убытки будут многомиллионными? Как считал? Под какую нагрузку/какой бизнес?
У меня есть данные от нескольких очень крупных падений Oracle, с многомиллионными убытками. Во всех случаях Oracle не заплатил напрямую ничего. Про Tibco аналогично слышал из первых рук, но сам не присутствовал.

C>>Чем мониторинг должен помочь?
I>Если твой мониторинг для твоего супер нагруженного/всегда доступного решения не умеет автоматически запускать disaster recovery procedure при детектировании того что все упало, то я в недоумении.
Что она даст, если критические компоненты не работают? Куда будет disaster recovery, если состояние системы неопределенное из-за того, что очередь сообщений скопытилась?

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

I>Далее, кто мешает клиенту по таймеру читать из специального ендойнта текущую загрузку системы и изменять величину отклика(время показа окошка please wait) клиенту чтобы тот не так сильно дергался и при полной жопе показывать окошко "попробуйте через 10 минут".
Как это будет выглядеть на уровне API для клиентов?

C>>Но в данном случае это не поможет, так как при замедлении обработчика, он не будет справляться с нормальным потоком сообщений, которые вполне себе уникальны.
I>Еще как поможет, разгребет потихоньку если входной поток ограничить как я описал выше.
А нафиг он тогда нужен? Не проще ли использовать синхронные вызовы?

I> их заново с нужным уровнем надежности банально слишкеом дорого и никому нафик не надо. Но гарантировать доставку сообщений с вероятность в 99.9+ задешево — мечта бизнеса. Вот тут очереди/сервис басы решают.
А бэкэнд всё равно должен быть надёжен, так как иначе никакие 100500 девяток в SLA не помогут.

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

I>Тоесть "прокачанный сеньор". Адекватно, в своей специализации ты прокачался, но по сторонам смотреть пока еще не очень научился, а может тебе оно и не сильно нужно.
Это очень прокачанный сеньор. И как раз на системы клиентов и внутренние системы Amazon'а я насмотрелся вдоволь.