Реализация кэша Hazelcast в моем приложении

Question

Ниже мой сценарий с точки зрения приложения.

У нас есть 2 файла приложений (.war), которые будут работать на одном и том же экземпляре сервера приложений (в основном Tomcat 8). В производственном процессе мы можем развернуть App1 на 100 серверах и App2 только на 50 серверах из этих 100 (App2 не требуется). так много раздаётся)

Теперь эти 2 приложения (.war) зависят от общего пользовательского jar (некоторые служебные классы)

Я планирую использовать Jcache API и реализацию hazelcast в наших приложениях. Я добавил следующие зависимости в моем pom.xml

<!-- JSR 107 JCache -->
    <dependency>
        <groupId>javax.cache</groupId>
        <artifactId>cache-api</artifactId>
        <version>1.0.0</version>
    </dependency>
    <!-- Hazelcast dependency -->
    <dependency>
        <groupId>com.hazelcast</groupId>
        <artifactId>hazelcast</artifactId>
        <version>3.4</version>
    </dependency>

Планируется написать утилиту CacheManager в этом обычном пользовательском банке, который будет использоваться App1 и App2.

Я планирую использовать только провайдера Hazelcast Server, как я делаю в кластере памяти, т.е. кэширование будет в памяти приложения.

Ниже приведен фрагмент моего кода.

public class PPCacheManager {

// Loads the default CacheProvider (HazelCast) from hazelcast.xml which is
// in classpath
private static CachingProvider defaultCachingProvider = Caching.getCachingProvider(); //
// Loads the default CacheManager from hazelcast.xml which is in classpath
private static CacheManager defaultCacheManager = defaultCachingProvider.getCacheManager();
// Some more code goes here...

Мой hazelast.xml

<hazelcast xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.hazelcast.com/schema/config
                           http://www.hazelcast.com/schema/config/hazelcast-config-3.4.xsd"
       xmlns="http://www.hazelcast.com/schema/config">



<cache name="commonClientCache">
    <key-type class-name="java.lang.String"></key-type>
    <value-type class-name="java.lang.Object"></value-type>
    <statistics-enabled>true</statistics-enabled>
    <management-enabled>true</management-enabled>
    <read-through>true</read-through>
</cache>
</hazelcast>

Теперь у меня есть несколько вопросов относительно этого подхода.

1. Является ли это хорошим способом реализации кэширования в памяти (в настоящее время мы не ищем кластерное кэширование), должен ли этот код находиться в обычном пользовательском фляге или где-то еще?

2. Есть некоторые основные данные из БД, которые я планирую загрузить (оба приложения нуждаются в этих данных), поэтому не уверен, как и где мне загрузить эти данные в память. Примечание: я не хочу выполнять отложенную загрузку... Я хочу загрузить эти основные данные в первую очередь.

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

Любые другие предложения или помощь от вас приветствуется.

ОБНОВИТЬ

Кроме того, благодаря реализации этого подхода у меня будет 2 копии кеша для приложения, или одна копия будет распределена между обоими.

Я уже реализовал этот подход в своем приложении, и из консоли управления Hazelcast я вижу, что создается только 1 кеш, но он говорит, что GET выполняется в этом кеше дважды...

Answer 1

Hazelcast является идеальным решением для того, что вы пытаетесь сделать. Определенно нет ленивой загрузки. Вам не нужно ничего подобного, если у вас есть общая память.

Что касается того, сколько экземпляров у вас будет в одной (Tomcat) JVM, у вас будет два, если вы создадите экземпляр Hazelcast дважды. Это будет автоинкремент порта. Однако оба будут принадлежать одному кластеру (вы называете "кеш"), если имя кластера одинаковое. Так что, кроме того, что выглядишь немного глупо (осколочно на одной JVM), ты в порядке. Чтобы избежать этого, вы можете настроить одну из войн для создания экземпляра HazelcastClient. Утилита jar может быть такой же. Все должно быть в каком-то, например, конфигурационном файле Spring - каждая война будет иметь свою собственную копию. Или вы можете поместить этот конфиг в два внешних каталога и добавить в путь к классам catalina.

Код выключения принадлежит тому же месту, в котором вы создали Hazelcast, т.е. ваши две войны будут иметь два вызова выключения. Вы можете сделать это в destroy() Spring любого из ваших высокоуровневых конфигурационных (или автоматически подключаемых) компонентов или поместить его в прослушиватель сеансов Web App.