И вот, наконец, мы добрались до файла ignite-config.xml.
Буду разбирать его по кусочкам, т.к. целиком в один скриншот он вряд ли влезет. Да и объяснять, где в нём что, будет проще на небольших кусочках. Полностью этот файл можно будет посмотреть в репозитории проекта.
Объявляем схемы, которые будем использовать в нашем конфиге. Как видите, используются схемы Spring framework. Сам Apache Ignite работает на Spring. И в его конфигурационном файле можно использовать все те же инструменты, что и при XML-конфигурировании Spring-бинов. Это очень большой плюс, т.к. существенно расширяет наши возможности по переносу всей конфигурации Ignite во внешний файл.
Добавляем в переменные окружения флаг, указывающий нодам использовать для сетевого взаимодействия протокол IPv4. Согласно документации Apache Ignite, с протоколом IPv6 кластер работает нестабильно. В продакшене нам нужна стабильность. Поэтому наш выбор - IPv4.
Отключаем обмен классами между нодами по протоколу P2P. Согласно документации Apache Ignite, такой обмен классами, позволяет нодам обмениваться друг с другом классами. Как показывает практика, работает эта штука не для всех случаев и несколько замедляет работу кластера. Например, я из описания этой фичи понял, что можно копировать наш сервис в директорию libs не всех нод, а только одной. И она уже перешлёт его классы остальным нодам. Но у меня это не заработало и пришлось синхронизировать директории libs на всех нодах самстоятельно. Есть всего один случай, когда PeerClassLoading мне пригодился, но о нём я расскажу позднее, когда буду писать внешнего клиента для нашего кеша.
Т.к., кроме стабильности, в продакшене важна также скорость работы, отключаем PeerClassLoading.
Конфигурируем TcpDiscoverySpi. Здесь мы говорим кластеру, что все ноды, входящие в кластер, ему нужно искать в списке addresses. Согласно документации, если использовать настройки по умолчанию, то каждая нода будет искать другие ноды по всему диапазону доступных адресов. Когда нод в кластере много, то время, необходимое для запуска кластера, может существенно возрасти.
Кроме того, при дефолтных настройках в кластер могут попасть посторонние ноды, относящиеся к другому кластеру.
Голосуя в продакшене за стабильность и скорость, указываем нашему кластеру из одной ноды искать остальные ноды (которых нет) только на localhost.
- name - как они будут называться;
- maxPerNodeCount - количество экземпляров сервиса, которое будет запущено на каждой ноде;
- totalCount - количество экземпляров сервиса, которое будет запущено во всём в кластере. Эта настройка есть только у StartService и равна 1. Это значит, что такой сервис будет запущен в единственном экземпляре на весь кластер (cluster singleton). У ReviewRepository такой настройки нет и он будет запущен в одном экземпляре на каждой ноде;
- nodeFilter - указываем,по какому признаку кластер должен выбрать ноды, на которых будет запущен сервис. В нашем случае это должны быть ноды с ролью "service-node".
Конфигурируем наши кеши. У нас их два: один - для регистрации активности приложения, второй - для сохранения распарсенных данных. Задаём следующие параметры:
- name - имя кеша. В нашем случае это: activity_cache и review_cache. Этим именам должны соответствовать значения, которые мы добавили в наши PROPERTIES в классе ru.emi.ignitecache.utility.PropertyUtility нашего сервиса:
- cacheMode - поведение кеша. У нас это PARTITIONED - кеш будет разделён на части между нодами. Если будет три ноды, то на каждой из них будет находиться примерно 1/3 даных кеша;
- backups - количество резервных копий кеша. У нас их по одной на каждый кеш;
- statisticsEnabled - будет сервис отдавать метрики или нет. Третий столп, на котором держится продакшен - метрики. Поэтому ставим true.
Здесь я выделил кешу 4 ГБ памяти. Сделал это потому, что при больших объёмах данных Apache Ignite падал с ошибкой, говорящей о том, что ему не хватило памяти. Желающие более досконально разобраться с этим параметром, могут найти все подробности в документации Apache Ignite.
На этом конфигурирование нашего кластера закончено. Осталось:
- скопировать файл конфигурации в директорию config бинарной сборки Ignite,
- скопировать наш "толстый" jar-файл в директорию libs пакета Ignite,
- перейти в консоли в корень пакета бинарной сборки Ignite и выполнить команду:
$ ./bin/ignite.sh -v ./config/ignite-config.xml
