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

Филипп делится нюансами и способами организации распределённых транзакций в условиях микросервисной архитектуры на примере паттернов SAGA, Transactional outbox.
Полезные ссылки:
- zio-saga: github.com/Vla...
- cats-saga: github.com/Vla...
- transaction-outbox: github.com/gru...
- Saga pattern: microservices....
- Transactional Outbox pattern: microservices....
Наш телеграм канал - t.me/techm2
Наш Хабр - habr.com/ru/co...

[@intrigant_huev]

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

[@kuanyshrsymbetov6022]

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

[@JoelMiller-b9o]

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

[@SubaruImprezaEdet]

@@JoelMiller-b9o а у нас 500

[@Roman-ov8bi]

@@kuanyshrsymbetov6022 7:40 7:41

[@Roman-ov8bi]

@@kuanyshrsymbetov6022 7:50

[@bLzshka]

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

[@thecftyhn]

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

[@radiopapus]

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

[@semenivanoff8615]

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

[@neketavorotnikov6743]

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

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

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

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

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

[@ВалдисПельш-е4в]

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

[@user13496]

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

[@Iaxls]

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

[@MicP8]

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

[@niks4988]

Она нужна просто везде.

[@dmitriyobidin6049]

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

[@igor5379]

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

[@alexandr6055]

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

[@d31m07y1988]

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

[@profile_pub190]

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

[@victorm7551]

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

[@evilLincoln]

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

[@ivani3237]

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

[@YGNETATEL_3000]

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

[@yaroslavlymar6599]

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

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

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

[@АлексейПаршин-ч7е]

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

[@МихаилБаранов-ю2е]

Эдакий мини монолит выделить :)

[@sfiorashtirliz8132]

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

[@VyacheslavM1]

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

[@АртемУсманов-з6и]

пАттерн же

[@yadronn]

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

[@MrNegroist]

Спасибо за доклад. Очень понятно.

[@kozhurkin]

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

[@AlexSmith-pd8cn]

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

[@Thief1987]

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

[@incognito123q]

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

[@amonix4035]

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

[@DWGFragaed]

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

[@user-tw4sx]

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

[@JohnJohn31595]

thank you

[@eugenyvolkov7387]

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

[@howicanwin]

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