Кто как работает с распределенными транзакциями?

[Крот]

Всем привет!

Допустим, у нас имеется 2 инстанса mysql, пускай это будет 2 шарды с разными юзерами. Нужно монетки от юзера А передать юзеру Б таким образом, чтобы эти монетки гарантированно не потерялись. Какие есть варианты решения данной задачи? Из известных мне - 2х фазный коммит, который даже поддерживается mysql'ем (XA-транзакции), но что, если у нас связка mysql + redis или что-то типа этого.

Спасибо.

 

[WMix]

в чем именно проблема? как работает оплата Pay-Pal в онлайн магазине понимаешь?

 

[AmdY]

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

 

[Крот]

в чем именно проблема? как работает оплата Pay-Pal в онлайн магазине понимаешь?

Собственно проблема описана в посте - огранизация распределенной транзакции. Как работает оплата PP понимаю - создание транзакции на оплату, асинхронное получение отстука от PayPal о статусе транзакции (или самостоятельный запрос у PP статуса транзакции).

 

[Крот]

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

Спасибо.

Из того, что читал\смотрел - есть только 2 варианта: 2 phase commit и saga, см. https://developers.redhat.com/blog/2018/10/01/patterns-for-distributed-transactions-within-a-microservices-architecture

Из минусов 2-х фазного комммита - масштабируемость + координатор = single point of failure. Но в контексте моей задачи эти минусы не существенны. Пока решил хорошенько раскурить 2-х фазный коммит, попробую его реализовать. Сейчас есть ощущение, что не до конца понимаю.

 

[fixxxer]

что, если у нас связка mysql + redis или что-то типа этого

Ну, это, eventual consistency. Как еще-то.
Я не очень понимаю, как ты собрался делать 2PC в Redis
Если lua-скриптом с блокировкой, то у тебя 99% времени Redis будет заблокирован, и нафига он тогда нужен - mysql в той же роли будет эффективнее в тыщу раз.
Сагой делай.

 

[Крот]

Ну, это, eventual consistency. Как еще-то.
Я не очень понимаю, как ты собрался делать 2PC в Redis
Сагой делай.

Про redis я так.. ляпнул, согласен. 2PC мы и в mysql сделать не сможем, т.к. у нас несколько percona кластеров, а percona-cluster не умеет XA-транзакции. Спасибо, почитаю про саги.

 

[fixxxer]

Ваще забудь про мультимастеры и распределенные XA, даже если кто-то попытается, это сразу привет CAP-теореме. Это может быть относительно жизнеспособно в надежной корпоративной внутренней сети, но никак не в интернетах.

Надо сразу учиться жить с асинхронкой и eventual consistency, это реалии жизни. С нормальным event sourcing это не проблема вообще, это по факту - если исходить не из сферических коней в ваккуме, а из реалий - куда более надежная архитектура на самом деле, тут основная проблема - перестроить мышление

CQRS Journey Guide - must read. На усиленный пиар azure не обращай внимания, все паттерны реализуемы на том же mysql.

Download Book Download: Exploring CQRS and Event Sourcing from Official Microsoft Download Center

A journey into high scalability, availability and maintainability with Windows Azure

www.microsoft.com

 

[MiksIr]

Я не очень понимаю, как ты собрался делать 2PC в Redis
Если lua-скриптом с блокировкой, то у тебя 99% времени Redis будет заблокирован, и нафига он тогда нужен - mysql в той же роли будет эффективнее в тыщу раз.

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