Peer Class Loading#

Введение#

Если включена функциональность Peer Class Loading, код Java не нужно вручную развертывать (deploy) на каждом узле в кластере и повторно развертывать при каждом изменении. DataGrid автоматически загружает классы из узла, где они загружены в classpath, на узлы, в которых они будут использоваться.

Например, при запросе данных с помощью пользовательского преобразователя нужно определить логику только на клиентском узле, который инициирует вычисления. DataGrid загрузит классы для выполнения логики на нужные серверные узлы. Подробнее об использовании запросов написано в подразделе «Использование Cache Queries» раздела «Использование Key-Value API».

Peer Class Loading позволяет развертывать следующие типы классов:

Задачи и задания, которые отправляются через интерфейс Compute — подробнее написано в разделе «Распределенные вычисления».
Функции преобразования и фильтры, которые используются с запросами кеша (подробнее написано в подразделе «Использование Cache Queries» раздела «Использование Key-Value API») и continuous queries (подробнее написано в разделе «Использование API continuous query»).
StreamTransformer, StreamReceiver и StreamVisitor, которые используются с DataStreamer — подробнее написано в разделе Data Streaming.
Entry Processor — подробнее написано в подразделе «Коллокация вычислений с данными» раздела «Распределенные вычисления».

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

Внимание

Функциональность Peer Class Loading не развертывает классы ключей и объектов для записей, которые хранятся в кеше.

Важно

Функциональность Peer Class Loading позволяет любому клиенту развернуть пользовательский код в кластере. Если нужно использовать функциональность в производственной среде, убедитесь, что доступ к кластеру есть только у авторизованных пользователей.

Когда класс требуется на удаленных узлах:

DataGrid проверяет, доступен ли класс в локальном classpath, то есть загрузился ли он при инициализации системы — если да, класс возвращается. В этом случае Peer Class Loading не происходит.
Если класс недоступен локально, запрос на определение отправится исходному узлу. Узел отправит байт-код класса, он загрузится на рабочий (worker) узел. Это происходит один раз для каждого класса. Когда определение загружается на узел, повторная загрузка не требуется.

Развертывание сторонних библиотек

При использовании Peer Class Loading нужно знать о библиотеках, которые загружаются из peer-узлов, и библиотеках, доступных локально в classpath. Рекомендуется включить все сторонние библиотеки в classpath каждого узла — для этого скопируйте JAR-файлы в папку {IGNITE_HOME}/libs. Это позволит не передавать мегабайты сторонних классов на удаленные узлы каждый раз, когда меняется одна строка кода.

Включение Peer Class Loading#

Пример настройки функциональности Peer Class Loading

XML#

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    <!-- Включение Peer Class Loading. -->
    <property name="peerClassLoadingEnabled" value="true"/>
    <!-- Установите режим развертывания. -->
    <property name="deploymentMode" value="CONTINUOUS"/>
</bean>

Параметры, которые относятся к функциональности Peer Class Loading:

Параметр	Описание	Значение по умолчанию
`peerClassLoadingEnabled`	Включает/отключает Peer Class Loading	`false`
`deploymentMode`	Режим Peer Class Loading	`SHARED`
`peerClassLoadingExecutorService`	Настраивает пул потоков, который будет использоваться для Peer Class Loading. Если он не настроен, используется пул по умолчанию	`null`
`peerClassLoadingExecutorServiceShutdown`	Флаг выключения Executor сервиса Peer Class Loading. Если у флага установлено значение `true`, пул потоков Peer Class Loading принудительно выключается при остановке узла	`true`
`peerClassLoadingLocalClassPathExclude`	Список пакетов в пути к системному классу, которые нужно загрузить по протоколу P2P (даже если они существуют локально)	`null`
`peerClassLoadingMissedResourcesCacheSize`	Размер кеша пропущенных ресурсов. Чтобы избежать кеширования пропущенных ресурсов, установите значение `0`	`100`

Режимы Peer Class Loading#

PRIVATE и ISOLATED#

У классов, которые развернуты в одном и том же загрузчике (classloader) на узле-владельце классов (master-узле), также будет одинаковый загрузчик на рабочих (worker) узлах. Однако задачи, которые развернуты с разных узлов-владельцев, не используют один и тот же загрузчик классов на рабочих узлах. Это удобно, если нескольким разработчикам нужно работать с разными версиями одних и тех же классов.

Разницы между режимами развертывания PRIVATE и ISOLATED нет, так как аннотация @UserResource удалена. Эти константы сохранились по причинам обратной совместимости, одна из них может удалиться в ближайших релизах.

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

SHARED#

Режим развертывания по умолчанию. У классов с разными узлами-владельцами (master-узлами) c одинаковой версией пользователя будет одинаковый загрузчик (classloader) на рабочих (worker) узлах. Отмена развертывания (undeploy) классов происходит, когда все узлы-владельцы покидают кластер или когда меняется версия пользователя класса. Режим позволяет классам, которые развертывались с разных узлов-владельцев, совместно использовать одинаковые экземпляры ресурсов пользователя на рабочих узлах (подробнее в разделе ниже). По сравнению с режимом ISOLATED, в котором есть несколько загрузчиков с одним классом на одном узле-владельце, режим SHARED расширяет область развертывания для всех узлов-владельцев.

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

CONTINUOUS#

В режиме CONTINUOUS отмены развертывания (undeploy) классов не происходит, даже если все узлы-владельцы классов (master-узлы) покидают кластер. Отмена развертывания происходит только при изменении версии пользователя класса. Режим позволяет задачам из разных узлов-владельцев совместно использовать одинаковые экземпляры ресурсов пользователя на рабочих (worker) узлах. При использовании этого режима можно запустить несколько отдельных рабочих узлов, определить ресурсы пользователя на узлах-владельцах и инициализировать их на рабочих вне зависимости от того, к каким узлам-владельцам относятся ресурсы. В отличие от режима ISOLATED, у которого есть один загрузчик классов (classloader) на одном узле-владельце, режим CONTINUOUS расширяет область развертывания на все узлы-владельцы.

Отмена развертывания и версии пользователя#

У классов, которые развернули с помощью Peer Class Loading, есть собственный жизненный цикл. При определенных событиях (в зависимости от режима развертывания: когда узел-владелец класса (master-узел) покидает кластер или когда меняется версия пользователя) происходит отмена развертывания (undeploy) информации о классе на кластере. Определение класса удаляется со всех узлов, и связанные с определением класса ресурсы пользователя также могут удалиться (в зависимости от режима развертывания).

Версия пользователя важна при повторном развертывании классов для режимов SHARED и CONTINUOUS. По умолчанию DataGrid автоматически обнаруживает ситуации, когда изменился загрузчик классов (classloader) или перезапустился узел. Если нужно изменить и повторно развернуть код на узлах или (в случае режима CONTINUOUS) отменить развертывание, измените версию пользователя. Она указывается в файле META-INF/ignite.xml в classpath:

<!-- Версия пользователя. -->
<bean id="userVersion" class="java.lang.String">
    <constructor-arg value="0"/>
</bean>

По умолчанию все скрипты запуска DataGrid (ignite.sh или ignite.bat) выбирают версию пользователя из каталога IGNITE_HOME/config/userversion. Обычно достаточно обновить версию пользователя в этом каталоге. В случаях GAR- или JAR-развертываний нужно предоставить файл META-INF/ignite.xml с желаемой версией пользователя.