Допустим, есть 2pc и saga паттерны.
У первого - проблема с промежуточными этапами, когда prepare - ok, а в момент выполнения локальной транзакции все потухло.
У саги поведение (помимо сложности реализации) - read uncommited.
Так вот вопрос. Есть ли способ использовать микросервисы, когда есть нужда в транзакциях и консистентности данных, избегая костыльных реализаций транзакций?
Тот же ACID в РСУБД продумывался десятилетиями, с ведением журнала транзакций, изоляций и бла бла - в общем работает идеально. В случаях микросервисов мы костылим какие-то левые решения, которые не всегда дают профит
например в 2pc это когда на момент выполнения транзакции все рухнуло, а мы, например, отправили смску. Все. Результата нет, юзер в ярости. С монолитом такого не произошло бы.
В случае с сагами, то тут проблема в изоляции, и без какого-нибудь Kafka не обойтись, ибо только он может дать гарантию на 1) сохранение порядка сообщений 2) что сообщение будет отправлено ровно 1 раз
Оттого и вопрос - можно ли обойтись без всего этого, сохранив плюсы реализации транзакционных механизмов РСУБД на микросервисах?
p.s не спорю, что для того же кейса с смсками, можно было бы заюзать outbox какой нибудь, но ведь это проблему все равно не решает
Без чего "всего"? Отправка СМС - это необратимая операция. Ей нельзя сделать Rollback.
Что с монолитом что с микросервисом.
Видимо ты слишком рано отправил ее. Или не с тем смыслом. Пересмотри
этот flow. Если СМС о том что товар оплачен и доставлен - то это слишком сложно.
Разбей на 2 статуса. Сначала СМС о том что оплачен. И потом что доставлен на склад.
mayton2019, без этого все я имею в виду самопальной, костыльной реализации подобия ACID, просто нельзя ли упростить этот механизм контроля за данными?
где-то видел про платежку - что если деньги уже списали, а какой нибудь заказ не создался - retry strategy? а если и оно не пройдет? делать возврат? тот еще геморрой
в монолите кмк, если данные успешно создались, то уже потом только можно создавать ссылку на платеж.... короче даже сейчас я запутался что к чему, если честно.
forced, взять монолит, если все равно надо проверять что платежка не прошла ю, а потом делать компенсирующие транзакции, то нафига этот acid вообще нужен? тупо ради того чтобы удостовериться fk fk на лежит и связи проставились? дичь какая то.
forced, у Саги и Микросервисов - полно недостатков. Но этот стек является следующим витком эволюции в направлении слабо-связных систем. Такими системами например будут являться элементы космической связи. Это там где законы физики диктуют нам архитектуры. Нельзя построить ACID систему где узлы БД будут стоять на земле и на Луне. Это не работает. Такова физика этих процессов. И в эпоху освоения космоса и развития IOT мы все больше будем строить системы которые слабо связаны. У них не будет глобальной блокировки или глобальной траназкции. Нам придется работать в условиях отсутствия синхронизации. В условиях остуствия единых часов. В условиях когда сетевой пакет может быть просто потерян. Или сетка будет недоступная. Таков реальный мир.
Если у тебя стек и железо позволяет - бери спокойно монолит. Бери и не парься. И плевать тебе на Сагу.
вопрос касался потому, что рассматривая текущие вакансии на c#, все больше и больше компаний устремились в микросервисы. но когда я начал теряться в теории, то у них дофигища недостатков (SpOF, CQRS, идемпотентность, да много чего) , которые были решены еще в монолитную эпоху. да, кроме, пожалуй, горизонтального масштабирования и слабой связанности. Просто мне было интересно как с такими недостатками могут вообще существовать сложные проекты и работать адекватно. Да и взять просто - кучу оптимизаций в работе СУБД, ORM и прочего сейчас заменяются на какие-то "репозитории" (не, паттерн хороший, но не так как его реализуют в большинстве примеров), теряя перфоманс взамен на "чистоту" кода...
впрочем спасибо, но если есть инфа по каким-нибудь не знаю интересным источникам - рад буду принять
forced, в микросервисах всегда нужно придерживаться правила идемпотентности и будет вам счастье. Таже кафка гарантирует доставку сообщения хотябы один раз, т.е. одно и тоже сообщение может быть доставлено более одного раза, вот тут и поможет идемпотентность.
Оттого и вопрос - можно ли обойтись без всего этого, сохранив плюсы реализации транзакционных механизмов РСУБД на микросервисах?
Паттерны распред. транзакций от того и появились, что нельзя. У вас физически несколько разных БД на разных хостах. Транзакция это свойство систем хранения данных, когда мы атомарно фиксируем некоторое состояние системы в БД. В распределенной системе - в нескольких БД. Сайд эффекты типа отправки СМС не имеют никакого отношения к транзакциям. Либо отправляйте СМС после полной фиксации транзакции, либо как вариант используйте компенсирующую СМС, типа - "Извините мы ошиблись на самом деле мы не сделали того о чем мы писали в прошлой смс", но это уже в порядке бреда.
то, что это сайд эффект уже разобрались. меня конкретно интересует сейчас изолированность саги (конкурентность) и как в принципе соблюдать консистентность в случае микросервисов.
просто если говорить про ACID (где в некоторых книжках C - возлагают ответственность на само приложение, а не на субд), все понятно - там есть уровни изоляции, гарантирии на атомарность и прочий стаф
но как быть с микросервисами? я должен все это вручную делать? делать проверки на идемпотентность, добавлять версионизацию и каким-то образом контроллировать что транзакция в deadlock не упадет? есть хотя бы best practices по этому поводу? я много материалов перелопатил, но кроме как сухой теории что такое распределенные транзакции и типы их реализации ничего более.
пока это единственное, что отталкивает от микросервисов
Простой
Простой
Средний
Простой
