Добрый день, друзья! С понедельником всех!

Я задаю здесь вопрос, а потом плююсь читая все комментарии типа какой я дурак и зачем я вообще все это делаю и зарекаюсь здесь больше не писать. Но скажу вам, я не прав, в итоге все равно в той или иной степени я получал ответ на вопрос, за что спасибо всем вам!

Так вот, собственно вопрос. Есть у нас в приложении синглетоны (EJB, но не суть, могли бы быть и Spring). Все прекрасно до тех пор, пока мы не начали масштабировать свое приложение через loadbalancer. Т.е. у нас база одна, а серверов приложений может быть несколько, с одним и тем же продуктом, естественно. И через load balancer (мы используем т.н. sticky sessions) запросы уходят на тот или иной сервер. Между собой сервера не общаются. Если один сервер умер, все пользовательские сесси на нем умирают - это не критично в нашем случае. Но вопрос касательно синглетонов. Получается их несколько инстансов теперь, естественно. Так вот какие быват практики какой-то синхронизации между ними? Можно конечно синхронизироваться через БД (она-то одна), но бывают критические с точки зрения скорости сценарии.

забыл никДавай начнем с простого - а зачем именно синглтон нужен?

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

1. Например для кеширования application scoped данных (тут вы скажете не валяй дурака, используй специальный софт для кеша - согласен, руки еще не дошли, хотя кое-где уже использую ehcache) - хотя тут если несколько инстансов синглетона, это не критично - будет просто несколько инстансев кеша
2. А вот здесь более критично: приложение работает по floating лицензиям. Т.е. при старте мы считываем из файла лицензий сколько у нас свободных лицензий, и выставляем в синглетон как переменную. Когда пользователь логинится, мы уменьшаем счетчик на единичку, когда выходит из системы - увеличиваем. Если счетчик ноль, то ни один пользователь не может залогиниться (нет лицензий). Счетчик AtomicLong. Так вот и получится, что счетчиков-то в кластере несколько! А на базе синхронизироваться? Как-то медленно.

mad_nazgulrabiterТак вот какие быват практики какой-то синхронизации между ними? Можно конечно синхронизироваться через БД (она-то одна), но бывают критические с точки зрения скорости сценарии.

А разве сервера приложений эту проблему не решают?

Ну есть два подхода - типа sticky sessions и non-sticky sessions. Мы используем первый (сессии у нас жирные, так исторически сложилось, много SessionScoped бинов, поэтому между серверами их синхронизировать через shared disk, или как там еще - тяжело будет). Или можно только выборочно синхронизировать синглетоны?

забыл никrabiter1. Например для кеширования application scoped данных (тут вы скажете не валяй дурака, используй специальный софт для кеша - согласен, руки еще не дошли, хотя кое-где уже использую ehcache) - хотя тут если несколько инстансов синглетона, это не критично - будет просто несколько инстансев кеша

Все правильно - надо будет на каждый инстанс свой кэш, либо партитичионировать данные на каждый нод - свой кусок. Ну не суть, проблема решаемая, синглтон тут не нужен.
rabiter2. А вот здесь более критичноСчетчик AtomicLong. Так вот и получится, что счетчиков-то в кластере несколько! А на базе синхронизироваться? Как-то медленно.
Задача ясна, но проблем все равно не вижу. У вас же есть логика авторизации\аутентификации, так? Как она работает? Почему бы в этом сервисе не завести таблицу с этим счетчиком. Не будет это медленно(точнее не медленнее всех способов синхронизировать синглтон)

Можно посмотреть в сторону zookeeper еще, но это уже тяжелай артиллерия. Я бы избавлялся от синглтонов на корню. Это бутылочное горлышкр всегда и везде

У нас монолит, не отдельного сервиса авторизации - все приложение это один жирный EAR файл. В случае кластеров мы его деплоим на N WildFly инстансов и пускаем на них через loadbalancer в sticky-sessions режиме. Т.е. получается если у нас счетчик в памяти - то получится N его инстансов (у нас N WildFly инстансов)
Zookeeper посмотрю, не хочу городить огород, но интересно.
Синглетоны горлышко, согласен, но если о ни в оснвном для чтения, то все ок (для записи изредка, тогда lock, да).

PetroNotC SharpП. П. 2 - можно и сервис лицензий отдельно запустить как офис MS делает. Отдельный сервис в сетке считает лицензии.

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

Но, идея централизованного лицензионного сервера мне очень нравится! Но, не станет ли он бутылочным горлышком? По сути тот же синглетон вынесен в отдельный сервис. Все N инстансов WildFly будут к нему обращаться по http

забыл никrabiterпропущено...


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

Но, идея централизованного лицензионного сервера мне очень нравится! Но, не станет ли он бутылочным горлышком? По сути тот же синглетон вынесен в отдельный сервис. Все N инстансов WildFly будут к нему обращаться по http
Не должен стать по идее. Особенно если у вас операции простые типа инкремент\декремент

да, сами операции простые, горлышком не станет... Но издержки на транспорт до него и от него. Хотя микросевисы же как-то живут в этом. С другой стороны у нас же и так постоянно транспорт от клиент до сервера и обратно, что я его так боюсь)
Хорошая идая, спасибо!

PetroNotC Sharprabiterгорлышкомсмотря какие программисты у вас.
Можно вместо http, сделать винСервис или на линуксе демон. Будет моментально отвечать.

А это очень интересно, спасибо за идею. Есть джависты и .net. Думаю на java можно демон для linux написать (или посмотреть готовые решения).

ПылинкаrabiterТак вот, собственно вопрос. Есть у нас в приложении синглетоны (EJB, но не суть, могли бы быть и Spring).
Singleton Session Beans?

так мы их и используем (@javax.ejb.Singleton вы имеете ввиду?), но и получается, что сколько JVM, столько инстансев синглетонов.

KachalovrabiterА на базе синхронизироваться? Как-то медленно.
- в памяти распределенное хранилище, типа Infinispan и т п (смотря какой сервер приложений используете). На нем и синхронизируйтесь.

Спасибо, про Infinispan не слышал, но булы мысль про Redis или Ignite. Правда, я подумал, что это overkill :-)