Распределенные транзакции / Что выбрать? Saga или 2pc? / Как подружить микросервисы
ฝัง
- เผยแพร่เมื่อ 27 ก.ย. 2024
- Когда мы работаем в рамках одной базы данных - все просто. Но как быть, если партия велела перейти на микросервисы, у каждого из которых будет своя база? Что делать с транзакциями? Как спасти священный ACID? Что такое распределенные транзакции? Какие паттерны бывают? Чем паттерн Saga отличается от паттерна 2pc (двухфазного коммита)? И какой из паттернов лучше для нашей ситуации?
Ссылка на ролик про ACID - • Проблема транзакций в ...
Ссылка на ACID в wiki - ru.wikipedia.o...
Ссылка на англоязычную статью, откуда взяты схемы - developers.red...
java 2021
Да согласен! Консистентность данных это большая головная боль разрабов. особенно где быстро надо.
гениальное видео, спасибо огромное
Отличный материал! Лайк и подписка!
Спасибо!)
Музыка лишняя
норм
возможно, тише но норм.
Спасибо. Наглядно объяснил, как работает 2pc
Если кому интересно откуда пошло название saga, то ответ есть на стековерфлоу. Это просто от слова "сага" - как цепь взаимосвязанных событий.
Спасибо за видео.Коммент в поддержку!
Очень неплохо, благодарю.
Спасибо, очень полезное видео 👍
Спасибо!
А что из себя представляет процесс подготовки данных транзакции в 2pc паттерне? Какой механизм позволяет нам узнать будут данные failed или success? Если есть возможность дождаться ответа от prepare транзакций, почему мы не можем так же дождаться ответа от обычной транзакции, и в зависимости от её ответа выполнять или не выполнять следующую транзакцию?
Ответьте, пожалуйста, если найдется время)
Вся подготовка - это блокировка на запись ресурсов которые будут меняться. Сервис денег блокирует 20р, сервис заказов блокирует заказанный товар. Так что конкурирующие процессы эти ресурсы не смогут использовать. Когда блокировка всех русурсов участвующих в покупке успешна - запускаем вторую фазу - списание. А в обычной транзакции, однофазной, ты когда деньги списываешь - еще не знаеешь успешно ли пройдет создание заказа из сервиса заказов или нет. Ты списал 20р и разблокировал счет, а потом что делать если заказ не создался??? Хз. Ну вот SAGA и придумана для создания механизма как вернуть 20р из-за несозданного заказа, чтобы можно было не держать блокировку
при 2pc можно блокировать не изменение значения поля, а блокировать некий неснижаемый остаток, разрешая менять его другим запросам
ну для неуникальных объектов типа денег - так и делают. Для уникальных - типа билета на конкретное место в поезде - блокируют конкретный объект
А можно приболтать бизнес чтобы распределенных транзакций не было) Тот случай когда софт скилы эффективнее любого паттерна:) Но конечно не всегда такое возможно)
А как можно приболтать условный интернет-магазин или любой другой бизнес, где есть работа с деньгами?
тема раскрыта не полностью - что произойдет, если в 2PC одна транзакция в статусе Done, другая в статусе Failed? Как потом откатывать данные?
Здравствуйте. Народ не подскажите где можно найти нормальный проект(Saga pattern вместе с Spring boot)? Везде объяснения, но не могу найти с кодом.
Разве SAGA требует эвентов, и там же их две..В целом можно залочить ресурсы в базе без блокировок просто через state машину дополнитетльное поле статусов.
7:25 а если первый done, а второй не done (подтвердилась только 1-я транзакция) ?
В 2pc все равно же не атомарно потому что не факт что сможем отправить аборт. Чёт не понял
Спасибо
музыка громковата
Микросервисы - модно, но порождает головную боль, монолит - классика..
Этот спор технологий разрешит прорыв в переходе к новым сетевым протоколам и новые технологии передачи данных по кабелю.. разумеется в пользу монолита
Не обманывайте людей. В патерне Saga нет транзакции. Не нужно делать подмену понятий типа сказав "локальная транзакция". Почитайте что такое транзакция. Честно было бы сказать что в Sega вы отказываетесь от транзакции и в случае не удачи, пытаетесь восстановить в обратном порядке данные, в случае не сложных систем вы будете иметь редко проблемы, а в сложных.....
В 2pc есть свои нюансы, но это транзакция, в Sega ее нет, и тот кто решит это использовать должен об этом знать.
Сама сага состоит из цепочки локальных для каждого микросервиса транзакций. Внутри одного сервиса это именно обычная транзакция. Но между-сервисами сага ведёт себя как начальник: сервис А успешно выполнил транзу? Ок кидаю событие "успех" тогда сервис Б может приступить к своей локальной транзакции. Если она неуспешна - сага создаст событие сервис-Б-ошибка по которому сага запустит откат транзакции на сервис-А.
В координаторе создаётся какая то транзакция)) откуда и как можно без бд сощдать транзакцию, что за фантазии.
транзакция - это логическая сущность. Набор операций которые должны быть выполненны или все сразу или ниодна. Можно из без всякой бд создать транзакционный самописный механизм. В БД они просто есть всегда и из коробки
9:00 при подготовке понятно, а если при отправке команды commit один сервис упал и не закоммитил, как второй откатывать?
16:05 а что если мы упали на компенсационной транзакции и не смогли откатить?
После того, как все успешно сделали prepare и оркестратор (или как его там называют) начинает коммит на всех базах, пути назад нет. Если одна база не успела закоммитить и упала, то после рестарта та транзакция будет висеть, пока не дождется подтверждения коммита.
Компенсационные транзакции должны быть идемпотентными, то есть их можно выполнять сколько угодно результат не изменится
А если в 2pc не сработал abort()?
Или commit() одной из транзакций… также будет рассинхрон
если не сработал abort то надо городить отдельно логику которая это учтет, в самом шаблоне 2рс ответа нет на эту ситуацию.
Так, а что если в двухфазном комитете обе транзакции 'подготовились' успешно, но одна упала при коммите? Или с одной из бд потерялась связь? Этот вариант у вас не рассмотрен.
при ошибке в любой фазе надо откат делать
Это почему 2pc не работает в общем случае.
@@владимирсенцов-р1ю 2PC вообще не работает ни в каком случае так как на даёт абсолютно никаких гарантий и не решает проблем.
а если в 2pc на этапе коммита мы должны уже финально снять сумму - но снятие суммы это обращение к стороннему сервису - например апи банка и все упало - то что в этом случаи?
Отлично объяснили тему. Огромное спасибо)
Что делать с ситуацией когда сначала выбираются данные из базы и далее на их основе вычисляется некоторая бизнес логика, которая затем сохраняется в базу. Может быть ситуация, когда первый поток уже выбрал данные из базы, затем второй поток эти данные изменил, далее произошло событие об изменении, после чего первый поток продолжает вычислять бизнес-логику уже на основе неактуальных данных. Проблема из-за отсутствия изолированности, но тут мы даже компенсацию сделать не можем, так как событие об изменении приходит раньше, чем первый поток закончит свою работу.
очень понятно объяснил
Спасибо тебе! Очень доступно
Класс
Спасибо за доклад.
Разве для 2PC нельзя применить вариант снятия 20 рублей с баланса пользователя на стадии prepare? Чтобы не делать блокировку баланса для других транзакций
Нельзя. Вот представь, ситуацию, когда 20 р должны не сниматься а поступить на р/счет. Изначально на р/счету 0 р. Если первая трансакция еще не завершена, а вторая уже снимает эти 20 р за покупку какого-то товара и заканчивается успешно. Потом в первой происходит откат , а денег на р/счету уже нет
@@krasser650да в 2pc (которая по факту есть - пессимистический режим блокировок) так и нельзя. А вот в SAGA (которая по факту есть - оптимистический режим блокировок) - можно, т.к. там между первым событием и событием компенсации - баланс не заблокирован - и паралельные транзакции легко могут загнать в минус баланс. Для того и существуют 2 разных механизма, чтобы можно было выбрать - медленно, но надежно, или быстро - но с артефактами неконсистентности
12:30 - программисты пишут код в базе данных... Как это? Какой механизм позволяет использовать этот код, он же в бд?
Привет. Например PL/SQL (Procedural Language / Structured Query Language)
У нас чуть ли не вся система на PLSQL написана. Позволяет добиваться высокой скорости при обеспечении полноценного ACID. Для финансовых систем это важно.
При этом это всё равно получается дикий монолит с характерными проблемами.
Вот как раз и рассматриваю варианты переноса части логики в микросервисы, но самой большой проблемой сейчас является решение вопроса согласованного чтения.
Кроме того, для разных операций нужно обеспечивать быстродействие разного характера: в одном случае быстродействие потоковой обработки событий, в другом: быстродействие одной длинной распределённой, но чувствительной транзакции.
весьма!
Для 2pc: транзакционные вещи не должны выноситься в 2 микросервиса. Это не разный контекст, это один контекст. Всего должно было быть 3 микросервиса: тот, который про заказы знает, тот который про бабло знает и тот который считает заказы с баблом. Так вот запрос отправляется на 3 микросервис с транзакционной базой данных. Никаких распределённых транзакций. И когда всё ок, то два других микросервиса уменьшают кол-во продуктов у себя на основе данных их общего микросервиса с транзакциями, вычитают деньги. Т.е. по сути это 2 микросервиса на чтение и один на запись. И базы данных тут 2х видо: одна реляционная, и две nosql.
Если же у вас сделано так, как в видео, то вы на уровне проектирования неправильно определили границы контекста (частая проблема, при отсутствии опыта DDD). Не всегда контекст "заказов" это один сервис, контекст "счета" второй.
Так тут же нет контекста "счета" или это подобласть сервиса Order.
кошелек пользователя и заказы - такое разделение выглядит более чем правильно или я не понял ваш комментарий.
тогда вообще не нужны тут микросервисы, если их аж 3 уже надо.
@@ivani3237 обычно чтение данных происходит гораздо чаще, чем запись. Поэтому разумно вынести отдельно часть, которая записывает, чтобы ее не дергали с чтением. И две части, которые позволяют читать.