Распределенный контроль параллелизма

Question

Я работаю над этим уже несколько дней, и я нашел несколько решений, но ни одно из них не было невероятно простым или легким. Основная проблема заключается в следующем: у нас есть кластер из 10 машин, на каждом из которых работает одно и то же программное обеспечение на многопоточной платформе ESB. Я могу довольно легко справиться с проблемами параллелизма между потоками на одной машине, но как насчет параллелизма на одних и тех же данных на разных машинах?

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

Решения, с которыми я концептуально играл:

1. Использование нашей отказоустойчивой общей файловой системы для создания «блокирующих» файлов, которые будут проверяться каждой машиной в зависимости от клиента

2. Использование специальной таблицы в нашей базе данных и блокировка всей таблицы, чтобы выполнить «проверку и установку» для записи блокировки.

3. Использование Terracotta, серверного программного обеспечения с открытым исходным кодом, которое помогает в масштабировании, но использует модель со спицами.

4. Использование EHCache для синхронной репликации моих "блокировок" в памяти.

Я не могу себе представить, что я единственный человек, у которого когда-либо были подобные проблемы. Как ты это решил? Вы готовили что-то на месте или у вас есть любимый продукт стороннего производителя?

Answer 1

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

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

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

Answer 2

Я сделал простой сервис RMI двумя способами: блокировка и разблокировка. оба метода берут ключ (моя модель данных использовала UUID как pk, так что это был также ключ блокировки).

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

у меня это сработало.

Answer 3

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

Ваш сервер базы данных может иметь ресурсы специально для такого рода вещей. В MS-SQL Server есть блокировки приложений, которые можно использовать в процедурах sp_getapplock / sp_releaseapplock .