Смотрю на первую каритинку с монолитом, все в одном месте транзакции из коробки, понятно как с ними работать. Потом делим это все на домены, получаем сетевые накладные расходы, теряем изоляцию и строгую согласованность, добавляем кафку, добавляем доп таблицы, добавляем message relay. Выглядит это сложно. Доклад хороший.
Модули, библиотеки превентирующие нарушение изоляции модулей, обычный code review в конце концов и нет проблем с монолитом. Но да, нужна культура и совесть разрабов (-> компетенции), распределенка таких проблем просто физически не допустит
супер, спасибо. До этого видео думал что saga, это transaction-outbox, то есть когда нам нужно атомарно положить в базу и отправить в очередь. Но оказывается это ток подзадача более общей задач распределенных транзакций))
При двухфакторной аутентификации можно запускать изменения данных в нескольких сервисах параллельно, и только коммитить синхронно. Не обязательно ждать ответа первого чтобы запустить коммит во втором. Строгая связность флоу - тоже не очень хорошо, потому что у нас может быть динамический флоу, т.е. чеолвек условно может чекбоксами натыкивать что ему надо, и на основе этого нам нужные разные цепочки? Мы задолбаемся все хардкодить. Получается по факту нам опять же нужен какой-то контроллер, который будет решать, какие события он в шину отправляет в рамках конкретного заказа. Надо ли там бронировать машину или нет, а может вместо машины там нужен трансфер. А с трансферами такая лабуда, что некоторые отели могут их предоставлять бесплатно при снятии дорого номера, некоторые за отдельную плату, а у каких-то такой услуги вообще не будет и надо привлекать третью сторону(такси) и т.д. Просто создать 1 флоу не выйдет. А получается что в случае саги нам опять таки нужен какой-то координатор, потому что условный сервис бронирования машин не должен знать(а тем более решать) какое действие должно происходить следующим. Поэтому жаль, что не затронули Event sourcing.
А еще сагу можно не хореографией описать а оркестрацией, чтобы отдельные сервисы-оркестраторы вели все саги и управляли взаимодействием конечных микросервисов. Саги так же как в докладе ставить в очереди для outbox с целью повышения надежности при падении/остановке оркестраторов
Здравствуйте. Как обрабатывать такой кейс, когда например у саги 3-я по счету локальная транзакция не проходит, запускаются компенсационные транзакции на 1-м и 2-м шаге, и валится второй сервис и компенсационные действия на 2-ом и 1-ом шаге не выполняются?
Судя по презентации, докладчик не понимает что такое атомарность и согласованность. Например - атомарность, это когда несколько действий воспринимаются как одно. Что будет что после коммита первого сервиса какой-то сторонний сервис поменяет так данные что компенсирующая транзакция не сможет выполниться? Данные первого сервиса доступны (закоммичены) для сторонних сервисов в то времмя когда не закомиченны данные остальных сервисов? И где тут атомарность?
@@user13496так в этом и вопрос, что второй кейс с невыполнено совсем не прокатит, ты занёс деньги на баланс первого сервиса и пошёл дальше сагой, пока ты там ходишь, кто-то эти деньги уже снял или сам пользователь трансфернул, в саге что-то сломалось и пришла команда все откатывать, а отказывать то нечего, баланс пустой
Я так и не понял что будет если откат уже не возможен в сервисе который завершил свою часть. Н-р на эти записи уже другая транзакция наложила свои изменения
по идее эти данные надо держать неизменными до подтверждения. Тут кажется уже не техническая реализация нужна, а бизнес реализация. Если клиент сделал бронь и не дождавшись завершения саги например её оплатил, то при откате первой саги надо сначала откатить вторую. Не знаю можно ли расширять сагу на ходу. В таком сценарии ничего страшного, оплата возвращается. Но распределенные транзакции выглядят как последний довод, когда других альтернатив уже нет
А может пересмотреть границы микросервисов? Если к примеру выделить агрегат - направление путешествия, то можно в рамках него провести все требуемые бронирования в одной транзакции
Если мы накручиваем дорогие, то добавляем и мета для потенциальных ошибок. Если одно из звеньев упадет и не передаст сигнал ни вперёд ни назад? Всё встанет и не понятно как продолжить
А если в базах добавить еще одно логическое поле "подтверждено" и устанавливать там true если все транзакции прошли успешно. Клиенту в это время можно сообщать, что майбах выбран другим клиентом, но еще окончательно не забронирован. Можно его глянуть попозже.
Разберитесь получше, что такое уровни изоляции транзакций, В сценарии названном у вас как false positive - названные уровни изоляции - вам не помогут. эта задача решается только блокировкой на БД или другом каком то общем разделяемом ресурсе.
В зависимости от уровней изоляции под капотом также используюся блокировки на затронутые строки. На примере pg: * Для read committed - будет наложена блокировка на обновляемые строки и другие транзакции, меняющие те же строки, будут ждать пока транзакция, которая наложила блокировку, её отпустит (произойдет commit или rollback). Затем ожидающие транзакции перевыполнят запрос на обновления и первая из них снова наложит блокировку на записи. * Для repeatable read - такой же процесс, но только блокировка накладывается на записи при их выборке через select В примере с read committed тоже не должно возникнуть проблем, если запрос учитывает, что машина уже может быть не доступна (по флагу/статусу/кол-ву доступных машин), а не просто обновляет поле записи. Что-то вроде: update foo set availableCount = availableCount - 1 where id = 1 and availableCount > 0.
Вменяемый человек, сделал бы по другому - бронирование всех сущностей вынес бы в отдельный сервис а все остальное уже можно писать как угодно. Тогда не нужно мучатся с сагами и двуфазными коммитами, все уже решено на уровне базы. Но нет мы себе усложняем жизнь и создаем проблемы.
Очень понятно и просто обьяснил довольно сложную тему!
Смотрю на первую каритинку с монолитом, все в одном месте транзакции из коробки, понятно как с ними работать. Потом делим это все на домены, получаем сетевые накладные расходы, теряем изоляцию и строгую согласованность, добавляем кафку, добавляем доп таблицы, добавляем message relay. Выглядит это сложно. Доклад хороший.
С монолитами тяжелее работать.
Накосячил в одном месте - не работает все.
Разделенные среды на домены там все просто и понятно.
Модули, библиотеки превентирующие нарушение изоляции модулей, обычный code review в конце концов и нет проблем с монолитом.
Но да, нужна культура и совесть разрабов (-> компетенции), распределенка таких проблем просто физически не допустит
супер, спасибо. До этого видео думал что saga, это transaction-outbox, то есть когда нам нужно атомарно положить в базу и отправить в очередь. Но оказывается это ток подзадача более общей задач распределенных транзакций))
TH-cam нужна опция пропускать все “aaa..”
Она нужна просто везде.
Аааааа
Очень интересный доклад. Оказывается, можно в одной транзакции бронировать в нескольких тормознутых внешних сервисах ;-))
Наконец то хороший доклад где простыми словами рассказано о патерне Saga
Я б с такой фамилией на самолётах не летал
Шойгу Герасимов - где мои 'оркестраторы"?!!
В страну 404 самое то
@@JoelMiller-b9o а у нас 500
@@kuanyshrsymbetov6022 7:40 7:41
@@kuanyshrsymbetov6022 7:50
Хотелось бы услышать как писать этот компенсационный алгоритм, лучшие практики
Прекрасный доклад! Благодарю!
спасибо большое за интересный доклад!
При двухфакторной аутентификации можно запускать изменения данных в нескольких сервисах параллельно, и только коммитить синхронно. Не обязательно ждать ответа первого чтобы запустить коммит во втором.
Строгая связность флоу - тоже не очень хорошо, потому что у нас может быть динамический флоу, т.е. чеолвек условно может чекбоксами натыкивать что ему надо, и на основе этого нам нужные разные цепочки? Мы задолбаемся все хардкодить.
Получается по факту нам опять же нужен какой-то контроллер, который будет решать, какие события он в шину отправляет в рамках конкретного заказа. Надо ли там бронировать машину или нет, а может вместо машины там нужен трансфер. А с трансферами такая лабуда, что некоторые отели могут их предоставлять бесплатно при снятии дорого номера, некоторые за отдельную плату, а у каких-то такой услуги вообще не будет и надо привлекать третью сторону(такси) и т.д. Просто создать 1 флоу не выйдет.
А получается что в случае саги нам опять таки нужен какой-то координатор, потому что условный сервис бронирования машин не должен знать(а тем более решать) какое действие должно происходить следующим. Поэтому жаль, что не затронули Event sourcing.
А еще сагу можно не хореографией описать а оркестрацией, чтобы отдельные сервисы-оркестраторы вели все саги и управляли взаимодействием конечных микросервисов. Саги так же как в докладе ставить в очереди для outbox с целью повышения надежности при падении/остановке оркестраторов
Так может микро-сервисы для этой задачи не подходят?
Здравствуйте. Как обрабатывать такой кейс, когда например у саги 3-я по счету локальная транзакция не проходит, запускаются компенсационные транзакции на 1-м и 2-м шаге, и валится второй сервис и компенсационные действия на 2-ом и 1-ом шаге не выполняются?
Судя по презентации, докладчик не понимает что такое атомарность и согласованность. Например - атомарность, это когда несколько действий воспринимаются как одно. Что будет что после коммита первого сервиса какой-то сторонний сервис поменяет так данные что компенсирующая транзакция не сможет выполниться? Данные первого сервиса доступны (закоммичены) для сторонних сервисов в то времмя когда не закомиченны данные остальных сервисов? И где тут атомарность?
В контексте ACID атомарность по другому определяется, как в видео, то есть транзакция либо будет выполнена либо не будет выполнена совсем.
@@user13496так в этом и вопрос, что второй кейс с невыполнено совсем не прокатит, ты занёс деньги на баланс первого сервиса и пошёл дальше сагой, пока ты там ходишь, кто-то эти деньги уже снял или сам пользователь трансфернул, в саге что-то сломалось и пришла команда все откатывать, а отказывать то нечего, баланс пустой
Я так и не понял что будет если откат уже не возможен в сервисе который завершил свою часть. Н-р на эти записи уже другая транзакция наложила свои изменения
по идее эти данные надо держать неизменными до подтверждения. Тут кажется уже не техническая реализация нужна, а бизнес реализация. Если клиент сделал бронь и не дождавшись завершения саги например её оплатил, то при откате первой саги надо сначала откатить вторую. Не знаю можно ли расширять сагу на ходу. В таком сценарии ничего страшного, оплата возвращается. Но распределенные транзакции выглядят как последний довод, когда других альтернатив уже нет
Тоже интересен этот вопрос и именно из-за него смотрю сейчас разве доклады
thank you
А может пересмотреть границы микросервисов? Если к примеру выделить агрегат - направление путешествия, то можно в рамках него провести все требуемые бронирования в одной транзакции
Эдакий мини монолит выделить :)
почему Аурус стоит после Майбах?
С false positive не совсем понял. Причем чем здесь вообще саги? Где там сага?
согласен, как-будто бы лютый бред)
ждали самую медленную, потом начали ждать все три последовательно. 100% быстрее)
Если мы накручиваем дорогие, то добавляем и мета для потенциальных ошибок. Если одно из звеньев упадет и не передаст сигнал ни вперёд ни назад? Всё встанет и не понятно как продолжить
Вагнер уже и до Программирования дотянулся !
Узнаю Яндекс - все примеры исключительно на майбахах и аурусах
Шойгу, Герасимов, где с...а пдф?😂😂
А если в базах добавить еще одно логическое поле "подтверждено" и устанавливать там true если все транзакции прошли успешно. Клиенту в это время можно сообщать, что майбах выбран другим клиентом, но еще окончательно не забронирован. Можно его глянуть попозже.
8:35 здесь надо бы сказать, что компенсирующая транзакция тоже может не выполниться.
Я в восторге, вау 😙
Доклад интересный, но вот разрешение видео бы побольше сделать. Сложно смотреть на 4К телевизоре.
лучший совет про сагу - это избегать ее всеми способами, все.
Dirty read зачем-то какими-то обманутыми транзакциями обозвали
пАттерн же
роскошная рубашка
бро афигенно рассказывает понятными словами
но боже неужели нелзя было дома практиковаться чтоб без этих слов паразитов ))
Чего он остановиться не может хоть на секунду?
в outbox паттерне сначала читают ивент из очереди, а потом контент этого ивента достают из БД, а не наоборот)
Суть же записать евент в базу в рамках транзакции чтобы его не потерять. Как его можно прочитать если он не создался
Он че вагнеровец
Какой замусоренный язык. Русским его назвать сложно
Разберитесь получше, что такое уровни изоляции транзакций, В сценарии названном у вас как false positive - названные уровни изоляции - вам не помогут. эта задача решается только блокировкой на БД или другом каком то общем разделяемом ресурсе.
В зависимости от уровней изоляции под капотом также используюся блокировки на затронутые строки. На примере pg:
* Для read committed - будет наложена блокировка на обновляемые строки и другие транзакции, меняющие те же строки, будут ждать пока транзакция, которая наложила блокировку, её отпустит (произойдет commit или rollback). Затем ожидающие транзакции перевыполнят запрос на обновления и первая из них снова наложит блокировку на записи.
* Для repeatable read - такой же процесс, но только блокировка накладывается на записи при их выборке через select
В примере с read committed тоже не должно возникнуть проблем, если запрос учитывает, что машина уже может быть не доступна (по флагу/статусу/кол-ву доступных машин), а не просто обновляет поле записи. Что-то вроде: update foo set availableCount = availableCount - 1 where id = 1 and availableCount > 0.
Да тоже кажется что не помогут. И вообще при чем там сага была не понятно.
Вменяемый человек, сделал бы по другому - бронирование всех сущностей вынес бы в отдельный сервис а все остальное уже можно писать как угодно. Тогда не нужно мучатся с сагами и двуфазными коммитами, все уже решено на уровне базы. Но нет мы себе усложняем жизнь и создаем проблемы.
Чел ты по-хорошему и описал 2фк