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

имеет ли Trasaction maanger возможность обрабатывать проблему параллелизма в сценариях распределенной базы данных.

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

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

Для такого типа запросов вы можете обрабатывать через Optimistic Concurrency, где у вас будет столбец в базе данных (Timestamp) в качестве ссылки на номер версии.

Каждый раз, когда фиксируется изменение, оно изменяет значение временной метки.

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

Диспетчер транзакций (как реализация спецификации JTA) делает прозрачной работу над несколькими ресурсами. Это гарантирует, что все операции выполняются как единое целое. «Работа над несколькими ресурсами» означает, что приложение может вставлять данные в базу данных и тем временем отправлять сообщение брокеру JMS. Диспетчер транзакций гарантирует сохранение свойств ACID для этих двух операций. В упрощенной форме, когда транзакция завершается успешно, разработчик приложения может быть уверен, что обе операции были обработаны. Когда возникают какие-то проблемы, их обрабатывает диспетчер транзакций - возможно, вызовет исключение и откатит изменения данных. Таким образом, ни одна операция не была обработана. Это делает это прозрачным для разработчика приложения, которому не нужно заботиться об обновлении сначала базы данных, а затем JMS, и проверяет, действительно ли были обработаны все изменения данных или произошел сбой.

В целом спецификация JTA не была написана с учетом архитектуры микросервисов. Теперь это действительно зависит от дизайна вашей системы (!). Но если учесть, что у вас есть два микросервиса, каждый из которых имеет свой собственный диспетчер транзакций, то диспетчер транзакций не сможет помочь вам решить проблему с параллелизмом. Менеджеры транзакций не работают (обычно) при некоторой синхронизации. Вы работаете не с несколькими ресурсами из одного микросервиса (каков вариант использования диспетчера транзакций), а с одним ресурсом из нескольких микросервисов.

Поскольку есть один ресурс, это точка синхронизации для всех ваших обновлений. От него зависит, как он управляет параллелизмом. Учитывая, что это база данных SQL, это зависит от уровня изоляции, которую она использует (ACID - I = изоляция, см. https://en.wikipedia.org/wiki/ACID_(computer_science)). В вашем конкретном примере говорится о феномене потери обновлений (https://vladmihalcea.com/a-beginners-guide-to-database-locking-and-the-lost-update-phenomen/). Так же обе микросервисы пытаются обновить одну запись. Одним из решений для предотвращения этой проблемы является использование оптимистической / пезимистической блокировки (вы можете реализовать ее самостоятельно, например, с помощью временных меток, как указано выше), другое - использовать сериализуемый уровень изоляции в вашей базе данных, или вы можете спроектировать свое приложение так, чтобы не читать и обновление данных на основе того, что было прочитано в первый раз, но измените запрос sql с атомарным обновлением (или, возможно, есть другие стратегии, как работать с вашей моделью данных для достижения желаемого результата).

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