Распределенные транзакции / Что выбрать? Saga или 2pc? / Как подружить микросервисы

Рет қаралды 21,742

3 жыл бұрын

Когда мы работаем в рамках одной базы данных - все просто. Но как быть, если партия велела перейти на микросервисы, у каждого из которых будет своя база? Что делать с транзакциями? Как спасти священный ACID? Что такое распределенные транзакции? Какие паттерны бывают? Чем паттерн Saga отличается от паттерна 2pc (двухфазного коммита)? И какой из паттернов лучше для нашей ситуации?
Ссылка на ролик про ACID - • Проблема транзакций в ...
Ссылка на ACID в wiki - ru.wikipedia.org/wiki/ACID
Ссылка на англоязычную статью, откуда взяты схемы - developers.redhat.com/blog/20...
java 2021

Пікірлер: 55

@ALEKS09FMF 3 жыл бұрын

Отлично объяснили тему. Огромное спасибо)

@user-xs3wx8vy8g 3 жыл бұрын

Да согласен! Консистентность данных это большая головная боль разрабов. особенно где быстро надо.

@dzen1234 Жыл бұрын

Если кому интересно откуда пошло название saga, то ответ есть на стековерфлоу. Это просто от слова "сага" - как цепь взаимосвязанных событий.

@jellyfish6265 6 ай бұрын

гениальное видео, спасибо огромное

@rinatbaygin7820 3 жыл бұрын

Отличный материал! Лайк и подписка!

@Alellas 3 жыл бұрын

Спасибо!)

@phil2964 Жыл бұрын

Спасибо, очень полезное видео 👍

@mouviem7951 Жыл бұрын

Спасибо тебе! Очень доступно

@iambusybox 3 жыл бұрын

Спасибо. Наглядно объяснил, как работает 2pc

@ocamlmail Жыл бұрын

Очень неплохо, благодарю.

@sovrinfo 2 жыл бұрын

Спасибо за видео.Коммент в поддержку!

@user-jt1xg1ez5m 2 ай бұрын

очень понятно объяснил

@tumenit Жыл бұрын

Спасибо!

@aidajam3294 3 жыл бұрын

Музыка лишняя

@FreemanFromSteppe Ай бұрын

норм

@sergeylebedev1052 Ай бұрын

возможно, тише но норм.

@depth5322 5 ай бұрын

Класс

@andreysakharov6210 3 жыл бұрын

весьма!

@alexeyfedorovich9769 Жыл бұрын

А что из себя представляет процесс подготовки данных транзакции в 2pc паттерне? Какой механизм позволяет нам узнать будут данные failed или success? Если есть возможность дождаться ответа от prepare транзакций, почему мы не можем так же дождаться ответа от обычной транзакции, и в зависимости от её ответа выполнять или не выполнять следующую транзакцию? Ответьте, пожалуйста, если найдется время)

@ivani3237 9 ай бұрын

Вся подготовка - это блокировка на запись ресурсов которые будут меняться. Сервис денег блокирует 20р, сервис заказов блокирует заказанный товар. Так что конкурирующие процессы эти ресурсы не смогут использовать. Когда блокировка всех русурсов участвующих в покупке успешна - запускаем вторую фазу - списание. А в обычной транзакции, однофазной, ты когда деньги списываешь - еще не знаеешь успешно ли пройдет создание заказа из сервиса заказов или нет. Ты списал 20р и разблокировал счет, а потом что делать если заказ не создался??? Хз. Ну вот SAGA и придумана для создания механизма как вернуть 20р из-за несозданного заказа, чтобы можно было не держать блокировку

@dovuddev5938 Жыл бұрын

Здравствуйте. Народ не подскажите где можно найти нормальный проект(Saga pattern вместе с Spring boot)? Везде объяснения, но не могу найти с кодом.

@VorobyovZuzex 4 ай бұрын

Теория это очень классно, а конкретно реализация будет показана? А то в ютюбе только видосы на индусском

@igorm.9845 Жыл бұрын

Так, а что если в двухфазном комитете обе транзакции 'подготовились' успешно, но одна упала при коммите? Или с одной из бд потерялась связь? Этот вариант у вас не рассмотрен.

@ivani3237 9 ай бұрын

при ошибке в любой фазе надо откат делать

@user-gw6df6ns7e 4 ай бұрын

Это почему 2pc не работает в общем случае.

@igorm.9845 4 ай бұрын

@@user-gw6df6ns7e 2PC вообще не работает ни в каком случае так как на даёт абсолютно никаких гарантий и не решает проблем.

@user-gm3sf9pe7q 4 ай бұрын

А можно приболтать бизнес чтобы распределенных транзакций не было) Тот случай когда софт скилы эффективнее любого паттерна:) Но конечно не всегда такое возможно)

@bormanbor8740 2 жыл бұрын

9:00 при подготовке понятно, а если при отправке команды commit один сервис упал и не закоммитил, как второй откатывать? 16:05 а что если мы упали на компенсационной транзакции и не смогли откатить?

@shprodt8841 2 жыл бұрын

После того, как все успешно сделали prepare и оркестратор (или как его там называют) начинает коммит на всех базах, пути назад нет. Если одна база не успела закоммитить и упала, то после рестарта та транзакция будет висеть, пока не дождется подтверждения коммита.

@omgoood 10 ай бұрын

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

@maksimmuruev423 Ай бұрын

Разве SAGA требует эвентов, и там же их две..В целом можно залочить ресурсы в базе без блокировок просто через state машину дополнитетльное поле статусов.

@TheSemenFarada 6 күн бұрын

а если в 2pc на этапе коммита мы должны уже финально снять сумму - но снятие суммы это обращение к стороннему сервису - например апи банка и все упало - то что в этом случаи?

@alex-0x6b 9 ай бұрын

А если в 2pc не сработал abort()?

@user-jd4rl7im6d 26 күн бұрын

Или commit() одной из транзакций… также будет рассинхрон

@test_bot5541 Жыл бұрын

7:25 а если первый done, а второй не done (подтвердилась только 1-я транзакция) ?

@serhii.koberniuk Жыл бұрын

Спасибо за доклад. Разве для 2PC нельзя применить вариант снятия 20 рублей с баланса пользователя на стадии prepare? Чтобы не делать блокировку баланса для других транзакций

@krasser650 10 ай бұрын

Нельзя. Вот представь, ситуацию, когда 20 р должны не сниматься а поступить на р/счет. Изначально на р/счету 0 р. Если первая трансакция еще не завершена, а вторая уже снимает эти 20 р за покупку какого-то товара и заканчивается успешно. Потом в первой происходит откат , а денег на р/счету уже нет

@ivani3237 9 ай бұрын

@@krasser650да в 2pc (которая по факту есть - пессимистический режим блокировок) так и нельзя. А вот в SAGA (которая по факту есть - оптимистический режим блокировок) - можно, т.к. там между первым событием и событием компенсации - баланс не заблокирован - и паралельные транзакции легко могут загнать в минус баланс. Для того и существуют 2 разных механизма, чтобы можно было выбрать - медленно, но надежно, или быстро - но с артефактами неконсистентности

@mqtrade5743 3 жыл бұрын

12:30 - программисты пишут код в базе данных... Как это? Какой механизм позволяет использовать этот код, он же в бд?

@Alellas 3 жыл бұрын

Привет. Например PL/SQL (Procedural Language / Structured Query Language)

@thepmgzzz 3 жыл бұрын

У нас чуть ли не вся система на PLSQL написана. Позволяет добиваться высокой скорости при обеспечении полноценного ACID. Для финансовых систем это важно. При этом это всё равно получается дикий монолит с характерными проблемами. Вот как раз и рассматриваю варианты переноса части логики в микросервисы, но самой большой проблемой сейчас является решение вопроса согласованного чтения. Кроме того, для разных операций нужно обеспечивать быстродействие разного характера: в одном случае быстродействие потоковой обработки событий, в другом: быстродействие одной длинной распределённой, но чувствительной транзакции.

@timur2887 9 ай бұрын

при 2pc можно блокировать не изменение значения поля, а блокировать некий неснижаемый остаток, разрешая менять его другим запросам

@ivani3237 9 ай бұрын

ну для неуникальных объектов типа денег - так и делают. Для уникальных - типа билета на конкретное место в поезде - блокируют конкретный объект

@MyCambodia-yg8fy 7 ай бұрын

Спасибо

@user-ig1wm9cq9k Жыл бұрын

музыка громковата

@alexanderlagutin6359 Жыл бұрын

В 2pc все равно же не атомарно потому что не факт что сможем отправить аборт. Чёт не понял

@complicated2359 Жыл бұрын

В координаторе создаётся какая то транзакция)) откуда и как можно без бд сощдать транзакцию, что за фантазии.

@ivani3237 9 ай бұрын

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

@user-ll2xw7tn6v 2 жыл бұрын

Для 2pc: транзакционные вещи не должны выноситься в 2 микросервиса. Это не разный контекст, это один контекст. Всего должно было быть 3 микросервиса: тот, который про заказы знает, тот который про бабло знает и тот который считает заказы с баблом. Так вот запрос отправляется на 3 микросервис с транзакционной базой данных. Никаких распределённых транзакций. И когда всё ок, то два других микросервиса уменьшают кол-во продуктов у себя на основе данных их общего микросервиса с транзакциями, вычитают деньги. Т.е. по сути это 2 микросервиса на чтение и один на запись. И базы данных тут 2х видо: одна реляционная, и две nosql. Если же у вас сделано так, как в видео, то вы на уровне проектирования неправильно определили границы контекста (частая проблема, при отсутствии опыта DDD). Не всегда контекст "заказов" это один сервис, контекст "счета" второй.

@serhii.koberniuk Жыл бұрын

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

@ivani3237 9 ай бұрын

тогда вообще не нужны тут микросервисы, если их аж 3 уже надо.

@gaben-agent 8 ай бұрын

@@ivani3237 обычно чтение данных происходит гораздо чаще, чем запись. Поэтому разумно вынести отдельно часть, которая записывает, чтобы ее не дергали с чтением. И две части, которые позволяют читать.

@uidee4725 Жыл бұрын

Микросервисы - модно, но порождает головную боль, монолит - классика.. Этот спор технологий разрешит прорыв в переходе к новым сетевым протоколам и новые технологии передачи данных по кабелю.. разумеется в пользу монолита

@thecftyhn 6 ай бұрын

Не обманывайте людей. В патерне Saga нет транзакции. Не нужно делать подмену понятий типа сказав "локальная транзакция". Почитайте что такое транзакция. Честно было бы сказать что в Sega вы отказываетесь от транзакции и в случае не удачи, пытаетесь восстановить в обратном порядке данные, в случае не сложных систем вы будете иметь редко проблемы, а в сложных..... В 2pc есть свои нюансы, но это транзакция, в Sega ее нет, и тот кто решит это использовать должен об этом знать.