Spring MVC с Soap Сервисом Многопоточность и Многосерверность

Question

Я пытаюсь создать небольшое приложение Sping MVC с параллелизмом. Сценарий :

1: Я использую WAS Websphere Server с 4 узлами с Балансировщик нагрузки

2: у меня есть 2 модуля: (a) веб-модуль (b) сервисный модуль с Soap веб-сервисом

3: веб-уровень вызывает сервисный уровень с помощью WebServiceTemplate .

4: Сервисный уровень имеет некоторые бизнес-логики c, такие как: расчет общей суммы депонирования, снятие и т. Д. c.

Подходы, которые я использовал:

1: я использовал синхронизированный в бизнес-логике c методы "Ввод, вывод" и c - не работал

2: я не использовал Scope в @Controller (я знаю, что это Singleton)

Вопрос:

Действительно ли я Нужно изменить область действия @Controller на «Запрос»?

Мое предположение: если я изменю область действия на Запрос , не замедлит ли это приложение? Например, даже для получения записей (без запроса на изменение) он будет замедляться

. Какие подходы мы можем использовать для создания единственной части кода - «Снятие» или «Депозит» Поток безопасен в сервисном модуле?

Answer 1

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

Вы должны использовать что-то, что управляет синхронизацией извне. Для этого я использовал Redis с библиотекой Redisson на Java.

1. Установить экземпляр Redis
2. Добавить Redisson в качестве зависимости от вашего проекта
3. Инициализировать класс RedissonClient
4. При доступе к критическому разделу (который является Withdraw или Deposit) вы получаете блокировку с помощью RedissonClient и снимаете ее после завершения операции.

При этом информация о синхронизации будет храниться в Redis, и все экземпляры будут совместно использовать ее, что не позволит никому войти в критическую секцию.

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