Как гарантируется ACID в распределенных транзакциях (по мотивам мутной статьи)?

Question

[footballer]

Прочитал на хабре статью о транзакциях между микросервисами.
https://habr.com/ru/company/piter/blog/522366/
Ну, как обычно и бывает, много написано, как должны работать эти все великолепные технологии, а по сути, если вдумываться, то понимаешь, что ничего в реальности работать и не должно. Получилась статья "мы вам все доказали, что оно гарантированно работает!", а по факту в статье ничего не доказано, что оно вообще работает. По-крайней мере, я ничего не понял.
Там говорится, что есть 2 варианта распределенных транзакций: 1) двухфазная фиксация и 2) SAGA.

Так вот, насчет первой, как понял: 2 микросервиса по команде координатора выполняют BIGIN TRANSACTION и сразу же затем UPDATE/INSERT/DELETE в БД , если все успешно, то отдают координатору ответ, что все ОК. Когда координатор получает от обоих микросервисов ответ, что все ОК, то он обоим отправляет команду COMMIT. И в статье говорится, что якобы происходит коммит в обоих микросервисах и, все данные согласованы и все становится зашибись. Ну так а где кейс, когда COMMIT дошел только до одного из микросервисов, и не дошел до другого (обрыв сети, например)? Очевидно же, что в этом случае коммит случится только в 1 сервис, а в другой нет, в итоге данные будут не согласованы. Как это вообще работать по факту должно? Ничего в статье не описано.

Второй вариант - SAGA - там вообще муть. Якобы сервисы обмениваются событиями через шину сообщений с координатором, если оба сервиса успешно выполнили UPDATE/INSERT/DELETE, то они отдают событие OK , если нет, то FAILED, и якобы если координатору пришел ОК от первого сервиса и FAILED от второго, то координатор отправил событие ROLLBACK первому сервису. И якобы опять на бумаге получается, что все идеально, четко, гарантированно! ДА с чего вдруг? А если до шины твое событие ROLLBACK не дошло (обрыв сети или еще что), тогда что?

Я понимаю, как работают транзакции внутри одной БД, я читал про алгоритм в механизме транзакций, поэтому понимаю, что внутри одной БД это реализуемо. И когда пытаюсь понять, как оно реализуется на уровне нескольких распределенных БД, то попадаю на подобные статьи, в которых одна только муть под видом научной литературы.

В общем, немного бомбануло. Но, может, кто-то все же по-нормальному объяснит принцип, каким образом гарантируется ACID в распределенных транзакциях?

Comments

[Ерлан Ибраев]

SAGA это не про ACID.
Атомарностью там даже не пахнет.
Согласованность ну очень специфичная.

Answer 1

[Михаил]

Гарантировать ACID возможно только с ограничениями. В данном случае, то о чем вы говорите, называется "жертвой устойчивости к распаду на секции (то есть сбоя в системе коммуникации между узлами)". См. теорема CAP

Answer 2

[Армянское Радио]

Те же вопросы имеются в комментариях к статье, там же и даны на них ответы: делается априорное утверждение, что вероятность того, что на шине произойдет сбой, является существенно более низкой, чем вероятность того, что транзакция будет отбита на стороне одной из СУБД.

Answer 3

[footballer]

Так судя по комментам в этом топике, двухфазная фиксация или SAGA - это в принципе НЕ ТРАНЗАКЦИИ, т.е. никакой фактической транзакционности там нет? Значит, любая система из связанных микросервисов априори не является надежной системой и всегда возможны потери данных? В любой банковской системе, если она микросервисная (а сейчас все такие), возможны несогласованные данные, и как итог потеря денег со счетов у клиентов из-за ошибок?
Насчет того, что сбой в сети намного менее вероятен (да и не только в сети, а где-нибудь даже на сервере), чем в СУБД, я не особо согласен, вообще часто бывает ситуация даже когда в браузере заходишь на сайт, а браузер выдает какую-нибудь ошибку сети, но стоит перезагрузить страницу, как сайтик загружается.

Answer 4

[Александр]

внутри одной БД это реализуемо.

Строго говоря, там точно также нет гарантий. Дисковая подситсема может сбойнуть в любой момент. К тому же сейчас диски часто сетевые...

Так судя по комментам в этом топике, двухфазная фиксация или SAGA - это в принципе НЕ ТРАНЗАКЦИИ, т.е. никакой фактической транзакционности там нет?

За SAGA не скажу, а вот двухфазная фиксация кроме того, что описано в статье, ещё должна, по идеи, так же как это делает отдельно стоящая СУБД, вести журнал логов перед началом транзакции. Возможно распределённый. Именно журнал (вернее его обработка) обеспечивает восстановление после аппаратных ( и в том числе сетевых сбоев). Сам же двухфазный комит гарантирует только то, что не будут записаны (и считаны до записи) несогласованные данные.

Значит, любая система из связанных микросервисов априори не является надежной системой и всегда возможны потери данных?

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