Singleton в Кластерной среде
если Вы знаете, передают изодромный с предварением из родительского процесса, вот сценарий оболочки, который должен работать:
for child in $(ps -o pid,ppid -ax | \
awk "{ if ( \$2 == $pid ) { print \$1 }}")
do
echo "Killing child process $child because ppid = $pid"
kill $child
done
9 ответов
Простейшие подходы:
Добавьте таймер истечения срока действия в одноэлементный кеш, чтобы время от времени кеш очищался, а последующие вызовы извлекали обновленные данные из источника (например, базы данных)
Реализуйте механизм уведомления для кеша, используя что-то вроде темы JMS / tibRV. Заставьте каждый экземпляр кеша подписаться и реагировать на любые сообщения об изменениях, передаваемые по этой теме.
Замените одноэлементный кеш на распределенный.
Одним из таких кешей может быть JBoss Infinispan , но я уверен, что существуют и другие технологии распределенного кэша и сетки, включая коммерческие, которые, вероятно, являются более зрелыми на данный момент.
В отношении одноэлементных объектов в целом я не уверен. Думаю, я бы вообще постарался не иметь синглтонов.
Или что-то вроде memcached
http://www.danga.com/memcached/
Что такое memcached? memcached - это высокопроизводительная распределенная память система кэширования объектов, общая в природы, но предназначен для использования в ускорение динамических веб-приложений за счет уменьшения нагрузки на базу данных.
Danga Interactive разработала memcached для увеличения скорости LiveJournal.com, сайт, который был уже делает 20 миллионов + динамических страниц просмотров в день для 1 миллиона пользователей с куча веб-серверов и куча серверы баз данных. memcached упал загрузка базы данных почти ничего, обеспечивая более быстрое время загрузки страницы для пользователи, лучшее использование ресурсов, и более быстрый доступ к базам данных на промах кэша памяти.
Если возможно, используйте для этого поддержку сервера приложений (у некоторых она есть, у некоторых нет). Например, мы используем поддержку JBoss для «синглтона высокой доступности», который представляет собой службу, которая работает только на главном узле кластера. Он не идеален (вы должны справиться с ситуацией, когда время от времени пукает мозг), но он достаточно хорош.
В противном случае вы сможете разработать что-то с помощью JGroups, который обеспечивает автоматическое обнаружение и согласование узлов кластера, но это нетривиально.
В крайнем случае, вы можете использовать блокировку базы данных для управления одиночными объектами кластера, но это серьезно хрупкое. Не рекомендуется.
В качестве альтернативы синглтону кластера вы можете использовать распределенный кэш. Я рекомендую JBossCache (который не для запуска требуется сервер приложений JBoss) или EhCache (который теперь предоставляет механизм распространения). Вам придется реинжиниринг вашего кеша, чтобы он работал распределенным образом (он не будет работать просто волшебным образом), но это, вероятно, будет лучшим решением, чем синглтон кластера.
Я с мистером Вестом Хансеном в этом деле, отойдите как можно дальше от одиночных игр. После того, как меня преследовал кошмар, связанный с SAAJ и JAXP, и я получил совместимые версии, работающие с JBoss, я покончил с синглтонами и фабриками. Сообщение SOAP не требует наличия фабрики для его создания.
Хорошо, разглагольствуйте, а как насчет кэша памяти или чего-то подобного? Какое сродство вам нужно для вашего кеша? Плохо, если они ВСЕГДА устарели, или есть некоторая гибкость в том, насколько устаревшими могут быть данные?
Есть несколько способов справиться с этим, в зависимости от 1) того, насколько закончились данные, и 2) все ли экземпляры должны иметь одни и те же значения все время.
Если вам просто нужны данные, которые являются разумно до данных, но каждая JVM не нуждается в соответствующих данных, вы можете просто заставить каждую jvm обновлять свои данные по одному и тому же расписанию (например, каждые 30 секунд).
Если обновление должно произойти примерно в В то же время вы можете настроить, чтобы один jvm отправлял сообщение остальным, говоря, что «пора обновить»
. Если каждому jvm всегда нужна одна и та же информация, вам нужно выполнить синхронизацию, где мастер говорит «обновить» now ", все кеши блокируют любые новые запросы, обновляются и сообщают мастеру, что они выполнены. Когда мастер получает ответ от каждого члена кластера, он отправляет другое сообщение, в котором говорится, что нужно продолжить.
Существуют продукты для распределения кеш-памяти в памяти (например, memcache), которые могут помочь в этой ситуации.
Лучшее решение, если возможно, может заключаться в том, чтобы синглтоны не совсем быть единым, но пусть приложение допускает наличие отдельных экземпляров (скажем, что все распознают, когда они должны быть обновлены), но не то, что они должны быть синхронизированы между JVM, что может превратить ваш кеш в узкое место.
Вы можете использовать DistributedMap , который встроен в БЫЛ.
-Рик
У меня аналогичная ситуация, но я использую Oracle WebLogic и Coherence .
Я работаю над веб-приложением, которое использует хэш-карту с кэшированными данными, считываемыми из базы данных (текст для отображения на ярлыках веб-формы ). Для этого разработчики использовали одноэлементный экземпляр, в котором они хранили всю эту информацию. Это хорошо сработало в среде с одним сервером, но теперь мы хотим перейти к кластерному решению, и я столкнулся с этой проблемой с этим экземпляром синглтона.
Из того, что я прочитал к настоящему моменту, это лучшее решение для достижения того, что я хочу . Надеюсь, это тоже поможет вам в решении вашей проблемы.