Филипп Вагнер "Распределенные транзакции в условиях микросервисной архитектуры"/M2_TECH Scala Meetup

Поделиться
HTML-код
  • Опубликовано: 23 дек 2024

Комментарии • 63

  • @bLzshka
    @bLzshka Год назад +12

    Очень понятно и просто обьяснил довольно сложную тему!

  • @ВалдисПельш-е4в
    @ВалдисПельш-е4в Год назад +1

    супер, спасибо. До этого видео думал что saga, это transaction-outbox, то есть когда нам нужно атомарно положить в базу и отправить в очередь. Но оказывается это ток подзадача более общей задач распределенных транзакций))

  • @СергейИванов-ы7ч5ы

    Очень интересный доклад. Оказывается, можно в одной транзакции бронировать в нескольких тормознутых внешних сервисах ;-))

  • @ДаниярКадырбеков-ъ6о

    Наконец то хороший доклад где простыми словами рассказано о патерне Saga

  • @radiopapus
    @radiopapus Год назад +25

    Смотрю на первую каритинку с монолитом, все в одном месте транзакции из коробки, понятно как с ними работать. Потом делим это все на домены, получаем сетевые накладные расходы, теряем изоляцию и строгую согласованность, добавляем кафку, добавляем доп таблицы, добавляем message relay. Выглядит это сложно. Доклад хороший.

    • @semenivanoff8615
      @semenivanoff8615 9 месяцев назад

      С монолитами тяжелее работать.
      Накосячил в одном месте - не работает все.
      Разделенные среды на домены там все просто и понятно.

    • @neketavorotnikov6743
      @neketavorotnikov6743 8 месяцев назад +1

      Модули, библиотеки превентирующие нарушение изоляции модулей, обычный code review в конце концов и нет проблем с монолитом.
      Но да, нужна культура и совесть разрабов (-> компетенции), распределенка таких проблем просто физически не допустит

  • @Iaxls
    @Iaxls Год назад +1

    Прекрасный доклад! Благодарю!

  • @user13496
    @user13496 3 месяца назад +4

    Хотелось бы услышать как писать этот компенсационный алгоритм, лучшие практики

  • @MicP8
    @MicP8 9 месяцев назад +16

    RUclips нужна опция пропускать все “aaa..”

  • @Сергей-у3к8й
    @Сергей-у3к8й 17 дней назад

    А почему бы над сервисами не поставить ещё один сервис, который и будет контролировать общее выполнение операции? Тогда обе проблемы исключены.

  • @dmitriyobidin6049
    @dmitriyobidin6049 Год назад +3

    При двухфакторной аутентификации можно запускать изменения данных в нескольких сервисах параллельно, и только коммитить синхронно. Не обязательно ждать ответа первого чтобы запустить коммит во втором.
    Строгая связность флоу - тоже не очень хорошо, потому что у нас может быть динамический флоу, т.е. чеолвек условно может чекбоксами натыкивать что ему надо, и на основе этого нам нужные разные цепочки? Мы задолбаемся все хардкодить.
    Получается по факту нам опять же нужен какой-то контроллер, который будет решать, какие события он в шину отправляет в рамках конкретного заказа. Надо ли там бронировать машину или нет, а может вместо машины там нужен трансфер. А с трансферами такая лабуда, что некоторые отели могут их предоставлять бесплатно при снятии дорого номера, некоторые за отдельную плату, а у каких-то такой услуги вообще не будет и надо привлекать третью сторону(такси) и т.д. Просто создать 1 флоу не выйдет.
    А получается что в случае саги нам опять таки нужен какой-то координатор, потому что условный сервис бронирования машин не должен знать(а тем более решать) какое действие должно происходить следующим. Поэтому жаль, что не затронули Event sourcing.

  • @timur2887
    @timur2887 6 дней назад

    А еще сагу можно не хореографией описать а оркестрацией, чтобы отдельные сервисы-оркестраторы вели все саги и управляли взаимодействием конечных микросервисов. Саги так же как в докладе ставить в очереди для outbox с целью повышения надежности при падении/остановке оркестраторов

  • @user-tw4sx
    @user-tw4sx Год назад +2

    Здравствуйте. Как обрабатывать такой кейс, когда например у саги 3-я по счету локальная транзакция не проходит, запускаются компенсационные транзакции на 1-м и 2-м шаге, и валится второй сервис и компенсационные действия на 2-ом и 1-ом шаге не выполняются?

  • @JohnJohn31595
    @JohnJohn31595 11 месяцев назад +2

    thank you

  • @intrigant_huev
    @intrigant_huev Год назад +163

    Я б с такой фамилией на самолётах не летал

    • @kuanyshrsymbetov6022
      @kuanyshrsymbetov6022 Год назад +38

      Шойгу Герасимов - где мои 'оркестраторы"?!!

    • @JoelMiller-b9o
      @JoelMiller-b9o 9 месяцев назад +2

      В страну 404 самое то

    • @SubaruImprezaEdet
      @SubaruImprezaEdet 6 месяцев назад

      @@JoelMiller-b9o а у нас 500

    • @Roman-ov8bi
      @Roman-ov8bi 5 месяцев назад

      @@kuanyshrsymbetov6022 7:40 7:41

    • @Roman-ov8bi
      @Roman-ov8bi 5 месяцев назад

      @@kuanyshrsymbetov6022 7:50

  • @d31m07y1988
    @d31m07y1988 10 месяцев назад +5

    Я так и не понял что будет если откат уже не возможен в сервисе который завершил свою часть. Н-р на эти записи уже другая транзакция наложила свои изменения

    • @profile_pub190
      @profile_pub190 7 месяцев назад

      по идее эти данные надо держать неизменными до подтверждения. Тут кажется уже не техническая реализация нужна, а бизнес реализация. Если клиент сделал бронь и не дождавшись завершения саги например её оплатил, то при откате первой саги надо сначала откатить вторую. Не знаю можно ли расширять сагу на ходу. В таком сценарии ничего страшного, оплата возвращается. Но распределенные транзакции выглядят как последний довод, когда других альтернатив уже нет

  • @thecftyhn
    @thecftyhn Год назад +12

    Судя по презентации, докладчик не понимает что такое атомарность и согласованность. Например - атомарность, это когда несколько действий воспринимаются как одно. Что будет что после коммита первого сервиса какой-то сторонний сервис поменяет так данные что компенсирующая транзакция не сможет выполниться? Данные первого сервиса доступны (закоммичены) для сторонних сервисов в то времмя когда не закомиченны данные остальных сервисов? И где тут атомарность?

    • @user13496
      @user13496 2 месяца назад +1

      В контексте ACID атомарность по другому определяется, как в видео, то есть транзакция либо будет выполнена либо не будет выполнена совсем.

    • @vitali1002
      @vitali1002 Месяц назад

      ​​@@user13496так в этом и вопрос, что второй кейс с невыполнено совсем не прокатит, ты занёс деньги на баланс первого сервиса и пошёл дальше сагой, пока ты там ходишь, кто-то эти деньги уже снял или сам пользователь трансфернул, в саге что-то сломалось и пришла команда все откатывать, а отказывать то нечего, баланс пустой

  • @victorm7551
    @victorm7551 2 месяца назад

    спасибо большое за интересный доклад!

  • @yadronn
    @yadronn Год назад +1

    почему Аурус стоит после Майбах?

  • @user13496
    @user13496 2 месяца назад +1

    С false positive не совсем понял. Причем чем здесь вообще саги? Где там сага?

    • @Lyroy__X
      @Lyroy__X 13 дней назад

      согласен, как-будто бы лютый бред)

  • @АлексейПаршин-ч7е
    @АлексейПаршин-ч7е 9 месяцев назад

    А может пересмотреть границы микросервисов? Если к примеру выделить агрегат - направление путешествия, то можно в рамках него провести все требуемые бронирования в одной транзакции

  • @ДаригаСолопиенко

    Я в восторге, вау 😙

  • @igor5379
    @igor5379 9 месяцев назад +3

    ждали самую медленную, потом начали ждать все три последовательно. 100% быстрее)

  • @nonpiramid
    @nonpiramid 2 месяца назад

    Если мы накручиваем дорогие, то добавляем и мета для потенциальных ошибок. Если одно из звеньев упадет и не передаст сигнал ни вперёд ни назад? Всё встанет и не понятно как продолжить

  • @VyacheslavM1
    @VyacheslavM1 7 месяцев назад

    8:35 здесь надо бы сказать, что компенсирующая транзакция тоже может не выполниться.

  • @sfiorashtirliz8132
    @sfiorashtirliz8132 9 месяцев назад

    А если в базах добавить еще одно логическое поле "подтверждено" и устанавливать там true если все транзакции прошли успешно. Клиенту в это время можно сообщать, что майбах выбран другим клиентом, но еще окончательно не забронирован. Можно его глянуть попозже.

  • @alexandr6055
    @alexandr6055 6 месяцев назад +3

    Шойгу, Герасимов, где с...а пдф?😂😂

  • @Wise___Man
    @Wise___Man 21 день назад +1

    лучший совет про сагу - это избегать ее всеми способами, все.

  • @ivani3237
    @ivani3237 Год назад +4

    Dirty read зачем-то какими-то обманутыми транзакциями обозвали

  • @YGNETATEL_3000
    @YGNETATEL_3000 8 месяцев назад +2

    Вагнер уже и до Программирования дотянулся !

  • @evilLincoln
    @evilLincoln 8 месяцев назад +2

    Узнаю Яндекс - все примеры исключительно на майбахах и аурусах

  • @yodo-y3i
    @yodo-y3i 6 месяцев назад +1

    пАттерн же

  • @kozhurkin
    @kozhurkin 6 месяцев назад

    роскошная рубашка

  • @Sergey09401
    @Sergey09401 Месяц назад

    бро афигенно рассказывает понятными словами
    но боже неужели нелзя было дома практиковаться чтоб без этих слов паразитов ))

  • @AlexSmith-pd8cn
    @AlexSmith-pd8cn Год назад

    Доклад интересный, но вот разрешение видео бы побольше сделать. Сложно смотреть на 4К телевизоре.

  • @yaroslavlymar6599
    @yaroslavlymar6599 5 месяцев назад

    в outbox паттерне сначала читают ивент из очереди, а потом контент этого ивента достают из БД, а не наоборот)

    • @ruslanvanzhula6823
      @ruslanvanzhula6823 2 месяца назад

      Суть же записать евент в базу в рамках транзакции чтобы его не потерять. Как его можно прочитать если он не создался

  • @incognito123q
    @incognito123q 9 месяцев назад +1

    Он че вагнеровец

  • @Thief1987
    @Thief1987 4 месяца назад

    Чего он остановиться не может хоть на секунду?

  • @amonix4035
    @amonix4035 6 месяцев назад

    Вменяемый человек, сделал бы по другому - бронирование всех сущностей вынес бы в отдельный сервис а все остальное уже можно писать как угодно. Тогда не нужно мучатся с сагами и двуфазными коммитами, все уже решено на уровне базы. Но нет мы себе усложняем жизнь и создаем проблемы.

    • @DWGFragaed
      @DWGFragaed 5 месяцев назад +1

      Чел ты по-хорошему и описал 2фк

  • @serge4031
    @serge4031 4 дня назад

    Какой замусоренный язык. Русским его назвать сложно

  • @eugenyvolkov7387
    @eugenyvolkov7387 Год назад +1

    Разберитесь получше, что такое уровни изоляции транзакций, В сценарии названном у вас как false positive - названные уровни изоляции - вам не помогут. эта задача решается только блокировкой на БД или другом каком то общем разделяемом ресурсе.

    • @howicanwin
      @howicanwin 9 месяцев назад

      В зависимости от уровней изоляции под капотом также используюся блокировки на затронутые строки. На примере pg:
      * Для read committed - будет наложена блокировка на обновляемые строки и другие транзакции, меняющие те же строки, будут ждать пока транзакция, которая наложила блокировку, её отпустит (произойдет commit или rollback). Затем ожидающие транзакции перевыполнят запрос на обновления и первая из них снова наложит блокировку на записи.
      * Для repeatable read - такой же процесс, но только блокировка накладывается на записи при их выборке через select
      В примере с read committed тоже не должно возникнуть проблем, если запрос учитывает, что машина уже может быть не доступна (по флагу/статусу/кол-ву доступных машин), а не просто обновляет поле записи. Что-то вроде: update foo set availableCount = availableCount - 1 where id = 1 and availableCount > 0.

    • @user13496
      @user13496 2 месяца назад

      Да тоже кажется что не помогут. И вообще при чем там сага была не понятно.