одного экземпляра (Singleton) класса в приложении Java развернутого во многих узлах

Question

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

1) БД на основе раствора

2) распределенного кэша

3) Шардинг

4) Поддерживать Singleton один случай балансировки нагрузки

Интервьюер ожидал чего-то большего, так как он ответил Основанный на БД и кеш будет работать, и осколки не сработают, и комментариев по поводу подхода балансировки нагрузки не будет, а затем добавил, что допустим, что подход БД и Кэш в вашем приложении не допускается , дайте мне другой вариант Я был застрял на этом этапе.

Тогда я гугл и нашел следующий

How to create singleton java class for multiple jvm support?

Singleton in Cluster environment

https://javaarchitectforum.com/2013/02/19/singleton-design-pattern-with-example/

Также нашел поддержку со стороны серверов приложений

http://www.onjava.com/pub/a/onjava/2003/08/20/jboss_clustering.html

http://docs.oracle.com/cd/E12840_01/wls/docs103/cluster/service_migration.html#wp1051458

http://docs.oracle.com/cd/E24152_01/Platform.10-1/ATGPlatformProgGuide/html/s1005runningthesameschedulableservice01.html

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

Answer 1

Все варианты подведет, если вы не знаете, что вы делает. Я бы назвал singleton анти-шаблоном, а не шаблоном проектирования, потому что способ, которым он часто используется, обычно является рецептом для катастрофы.

Теперь давайте перейдем к ответу. Вы должны спросить интервьюера: почему нужен один сингл? Какое состояние действительно нужно хранить в одном конкретном месте? Является ли это состояние изменчивым? Какова стратегия параллелизма? Будут ли в основном писать? Или в основном читает? Нужно ли синхронизировать весь доступ?

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

Теперь, давайте быстро пройти через варианты, которые Вы предоставили себя: решение на основе

1) DB

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

2) распределенного кэша

Это, по существу такой же, как раствор на основе БД. Вы могли бы даже написать свой собственный микросервис, чтобы выполнить эту работу.Вы должны понимать, что распределенный кеш точно так же, как и база данных, только тот, который оптимизирован для одновременного чтения по тем же данным (который имеет стратегию истечения срока действия). Имейте в виду, что если не объяснить, может возникнуть проблема с кэшированием, как если бы вы не знали, что кеш обычно недействителен/истекает и имеет резервную копию поколения. Это может звучать так, как будто вы не поняли проблему того, что хотите иметь одиночный экземпляр «живой» во все времена.

3) Sharding

Sharding техника, которую вы можете использовать, если ваш одноточечно слишком велик, чтобы поместиться в одном решении базы данных на основе упомянутого выше. Я очень сомневаюсь, что ваш синглтон станет таким большим.

4) Поддерживать Singleton одного экземпляра в балансировки нагрузки

Это делает ваш балансировки нагрузки шизофреник и плохая идея. Балансиры нагрузки - действительно простые компоненты, и должны оставаться такими.

Answer 2

Возможно, вы можете воспользоваться http://sw1nn.com/blog/2012/04/11/clojure-stm-what-why-how/ STM, который является техникой в ​​Clojure и, следовательно, должен работать на JVM. Кроме того, я согласен с тем, что сказал выше, как сказал Ян-Виллем Гмелиг Мейлинг. Это анти-шаблон, которого вы должны избегать. Мое предложение STM специально на языке, который не позволяет вам мутировать состояние, которое является предикатом для таких вещей, чтобы не стать опасным (это предотвратило бы разговоры о шизофренике, о которых говорит JWGM.)