Как разбить транзакцию по микросервисам сохранив консистентность данных?

Question

[Vitaliy Orlov]

Всем привет и с наступающим рождеством!

На собеседовании задали такую задачку:

В базе было несколько таблиц, в которые данные записывались с помощью транзакции. пусть это будет добавление данных.

Проект вырос и разделился на микросервисы. Теперь каждая таблица находится за отдельным микросервисом, в отдельной базе.

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

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

Пример:

transaction
-----------
id
service_1_saved - метка сохранение данных на сервисах
service_2_saved
service_3_saved
service_1_transaction_complete - метка выполнения транзакции на сервисах
service_2_transaction_complete
service_3_transaction_complete
complete - метка выполнение транзакции
fail_at - метка времени

service_1(2,3)
-----------
id
data
transaction_id
transaction_complete

Суть работы:

Этап 1) Передаем в сервисы данные и устанавливаем флаг service_1.transaction_complete = 0. Пока этот флаг равен 0, данные использовать нельзя. Далее передаем в ответе, что данные сохранены, тем самым устанавливая transaction.service_1_saved.

Этап 2) Если все сервисы обработали и сохранили данные (т.е. заполнены transaction.service_(1,2,3)_saved), считаем транзакцию успешной и обновляем флаг завершения транзакции на сервисах service_(1,2,3).transaction_complete = 1. В ответ обновляем transaction.service_(1,2,3)_transaction_complete = 1

Этап 3) Если все сервисы имеют transaction.service_(1,2,3)_transaction_complete = 1, то завершаем транзакцию устанавливая transaction.complete = 1

В случае провалов, чистим данные используя связь через transaction.id = transaction_id

Такой вот у меня получился транзакципед с сильной связанностью и не очень большой надежностью :)

Вопрос: как это делают правильно?

Comments

[longclaps]

На собеседовании задали такую задачку

Можешь не париться: идиоты, живущие в своём мире, где за целостность транзакций отвечает не SQL-сервер, а конгломерат самопальных микросервисов, хорошему не научат.
Микросервисы для другого: подтянуть к страничке жыпег, а не подтянулся - бог с ним, будет страничка без жыпега, всё лучше чем 404. Транзакционной целостностью там и не пахнет.

[sim3x]

Проект вырос и разделился на микросервисы. Теперь каждая таблица находится за отдельным микросервисом, в отдельной базе.

аргументация разнесения ключевого функционала - отсутствует
Потому микросервисы никто не применил и все отдано на откуп СУБД

Советую уточнить у них, используют ли они описанный подход у себя.
И если да, то поблагодарить и уйти

[Vitaliy Orlov]

Тут дело в другом, похожая задача, насколько я понимаю: хабр 1, хабр 2, хабр 3, может существовать и должны быть какие-то готовые решения. Т.е. к самой задаче-то претензий нет. Насколько я понимаю, крупные компании, все равно этот вопрос как-то решают. Относительно собеседования я не парюсь, меня теперь интересует как такое вообще проектируют и какие инструменты при этом используют.

Answer 1

[⚡ Kotobotov ⚡]

то что вы описали называется двухФазным комитом, раньше очень часто использовался.
сейчас активнее используют похожий но немного другой подход, тоже связанный с тем что резервируют определенные ресурсы (например деньги на счету, и товар на складе) потом проверяют промежуточный статус операции, и потом проводят и подтверждают операцию - разница в том что ничего не перезаписывается а непрерывно все запросы логируется, и любые откаты операции идут через добавление новых записей-запросов в лог (он же и очередь сообщений)
----
там много тонкостей, например вы говорили про время-метки, в целом метки времени добавляют - если нужно контролировать очередность промежуточных шагов (но обычно это не так важно, поэтому метку времени не всегда добавляют), но добавляют уникальный айди операции, тк в случае сбоя запроса (при например длительном ожидания ответа), может произойти "переотправка" запроса, и нам эта метка с уникальным айди позволяет не дублировать одну и туже операцию.
=====
есть тонкости например с тем, каким образом разделены эти микросервисы, может это просто дублирование одного и того же сервиса но например каждый из них обрабатывает запросы от разных сегментов пользователей, поэтому не требуется согласовывать какие-то операции между этими микросервисами.
====
на мой взгляд - это вобще разводные вопросы не имеющие правильного ответа, схемы подбираются конкретно под проект и задачи, тем более если вы не разрабатывали какую-нибудь платежную систему, типа яндекс.денег то вообще бесполезно что-то обсуждать.
это не камень в ваш огород, этим вообще обычно мало кто реально занимается, уверен те кто у вас это спрашивал сами мало что в этом понимают, а спрашивают такие вещи чтоб вас слить.

Comments

[Vitaliy Orlov]

Интересно, спасибо за ответ!

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

Насколько, я понимаю, вся суть этого вопроса была подводка к использованию CQRS + Event Sourcing о существовании которого я узнал из требований вакансии, наверно что-то большое делают/планируют, раз об этом спрашивают.

Но, теперь-то, интересно разобраться :)

P.S. Не думаю, что хотели слить, скорее ищут человека с большим опытом в решении проблем highload-а на крупных проектах.

P.S.2. Отмечу решением завтра, мб кто-то еще что-то посоветует.

[⚡ Kotobotov ⚡]

я не сталкивался, о чем разумеется сообщил

Vitaliy Orlov, ну если ищут человека с большим опытом, то какой смысл собеседовать человека который заведомо не подходит?
П. С.
хотеть можно много чего, обьективно в России проектов с хайлоадом на пальцах одной руки посчитать можно, а специалистов с большим опытом решений, да и еще свободных - вобще не существует)

[Vitaliy Orlov]

ну если ищут человека с большим опытом, то какой смысл собеседовать человека который заведомо не подходит?

Думаю, потому что оценивают набор навыков, а не какой-то конкретный.

хотеть можно много чего, обьективно в России проектов с хайлоадом на пальцах одной руки посчитать можно, а специалистов с большим опытом решений, да и еще свободных - вообще не существует)

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

Answer 2

[stratosmi]

1) Это некорректное разбиение на микросервисы, вообще-то. Так как приводит к серьезной проблеме с производительностью. И то, ради чего на микросервисы разбивали - горизонтальное масштабирование - получается и что бесполезно.

2) Если всё же вы решили забить на предупреждение из пункта 1), то - одно из решений - решается двухфазной транзакцией https://docs.microsoft.com/ru-ru/dotnet/framework/...

Answer 3

[JFeoksSs]

Паттерн Saga
https://microservices.io/patterns/data/saga.html

Answer 4

[index0h]

Если возникла проблема - очень большая вероятность того, что разделение на микросервисы было не корректным и стоит вернуться к монолиту.

Что касается распределенных транзакций. Как минимум можно пытаться повторять запросы N раз, в противном случае откатывать на каждом из сервисов.

Как вариант можно использовать всякие kafka для хранения истории сообщений с целью дальнейшего восстановления неотрботавших транзакций.

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

Правильного варианта не существует. Все зависит от проекта

Comments

[Vitaliy Orlov]

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

[index0h]

Vitaliy Orlov Понимаете какая фигня получается, абстрактные транзакции в сферических микросервисах в вакууме могут отработать, или не отработать по огромному списку причин.
Цель в том и заключается, что бы обойти ошибки, которые возникают по этому списку причин. Последние в свою очередь очень зависят от проекта.

Пример 1. У вас есть кластер метрик на каком-нить influxdb, запись параллельно происходит в каждую, чтение по round-robin. Допустим одна из нод отвалилась (ребут сервера), эта нода не может принимать запросы. В таких ситуациях стоит вести некий лог запросов на запись, что бы когда нода включилась обратно - она могла его дотянуть. Сервис управления кластером же должен считать, если например 4 из 5 успешно отработали, а одна - нет, запись прошла успешно.

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

Пример 3. У вас есть некий сервис, на который вы хотите налить трафика. Допустим сайты-партнеры, с которых идет наливка получают от вас уведомление о каждом приведенном пользователе посредством http запроса. По хорошему вы должны залоггировать у себя заход пользователя от партнера, а так же уведомить его об этом заходе, что бы баланс с обоих сторон сходился. Но партнер отвечает вам 500-й ошибкой. По идее нужно отправить запрос несколько раз, пока партнер не ответит 200 OK. Но тут есть момент: если трафика будет много, а партнерский сайт приуныл на 20 минут - вы его за DDOS-ите.

[Vitaliy Orlov]

Да, так оно и есть, но задача сводилась к тому, что было, например

БАЗА-ДАННЫХ

TRANSACTION BEGIN
INSERT INTO tbl-1
INSERT INTO tbl-2
INSERT INTO tbl-3
TRANSACTION END

а стало

БАЗА-ДАННЫХ-1
INSERT INTO tbl 1

БАЗА-ДАННЫХ-2
INSERT INTO tbl 2

БАЗА-ДАННЫХ-3
INSERT INTO tbl 3

и вопрос в том, как при новой архитектуре обеспечить согласованность данных в случае отказа например БАЗЫ-3, при условии что каждая из БАЗ находится за микросервисом (т.е. что там в итоге за хранилище мы можем и не знать, наружу только произвольное API)

[index0h]

Самое простое - это последовательно выполнять запись в каждом микросервисе. Если в 3ем произошел сбой - два предыдущих откатываем.

Answer 5

[Сергей Рогожкин]

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

Теперь представьте магию. Вы создаете заказ, который приводит к множеству параллельных, последовательных и очень сложно-разветвленных задач (резервирование на складе, отправка уведомлений, списание средств ит.п), в глубине которых что-то обламывается. Поскольку сервисы изолированы и почти ничего не знают друг о друге, надо всех причастных заставить вернуть "как было" через общий канал. Обломавшийся микросервис, зная ключ операции, кидает в шину сообщение "операция (id) не удалась, без подробностей". Далее все микросервисы: 1) откатывают операцию по id, если уже сделали 2) перестают реагировать на такой id, если еще не дошли запросы.
Итого: система вернулась в первоначальное состояние в целостном виде.

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

Answer 6

[Артемий]

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

Comments

[Сергей Рогожкин]

За "блокчейн" в приличных местах скоро в морду давать будут.

[Артемий]

а мне чем дальше, тем больше это решение нравиться для координации распределенных транзакций.

Answer 7

[khevse]

Однозначного ответа на данную задачу нет, потому что помимо сохранения консистентности данных могу быть дополнительные требования. Например:
- таблица слишком большая, поэтому применяется шардирование (оно же партиционирование);
- используется репликация с одним или несколькими ведущими узлами;
- требуется линеаризация;
- и т.д. и т.п. как по отдельности так и в совокупности.

Могу только порекомендовать вот эту книгу (сейчас сам её дочитываю):
https://www.piter.com/product/vysokonagruzhennye-p...
В ней очень подробно расписана работа с системами работающими с большими объемами данных.

Книгу нашел в вопросе:
Книга по распределенным отказоустойчивым системам?