Блог

В настоящее время я оцениваю использование Hazelcast для нашего программного обеспечения. Был бы рад, если бы вы могли помочь мне прояснить следующее.

У меня есть одно конкретное требование: я хочу иметь возможность динамически настраивать распределенные объекты (например, карты, очереди и т. Д.). То есть у меня не может быть всех данных конфигурации под рукой, когда я запускаю кластер. Я хочу иметь возможность инициализировать (и удалять) службы по требованию, а их конфигурацию, возможно, изменять между ними.

Версия, которую я оцениваю, — 3.6.2.

Имеющаяся у меня документация (справочное руководство, руководство по развертыванию, а также электронная книга «Освоение Hazelcast») очень скудна в деталях по этому вопросу и даже частично противоречит.

Итак, чтобы уточнить предполагаемое использование: я хочу запустить кластер; затем в какой-то момент создайте, скажем, распределенную структуру карты, используйте ее по узлам; затем утилизируйте ее и используйте карту с другой конфигурацией (скажем, количество резервных копий, политика удаления) для того жецели.

В документации упоминается, и этого следовало ожидать, что плохие вещи произойдут, если узлы будут иметь разные конфигурации для одного и того же распределенного объекта. Это имеет смысл и прекрасно; Я могу гарантировать, что конфигурации будут согласованы.

Глядя на код, казалось бы, можно сделать то, что я намереваюсь: при создании распределенного объекта, если у него еще нет прокси, HazelcastInstance просмотрит его конфигурацию, чтобы создать новую и сохранить ее в своем локальном списке прокси. Когда этот объект уничтожается, его прокси-сервер удаляется из списка. При следующем вызове он будет перезагружен из конфигурации. Кроме того, эта конфигурация доступна для записи, поэтому, если она была изменена между ними, она должна принять эти изменения.

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

• Есть ли какая-либо причина, по которой вышеупомянутое не должно работать?
• Если это должно сработать, есть ли какая-либо причина не делать вышеизложенное? Например, планируется ли изменить код в будущих выпусках таким образом, чтобы это не работало?
• Если да, есть ли какая-либо альтернатива?

Изменение конфигурации на лету для уже созданного распределенного объекта невозможно в текущей версии, хотя планируется добавить эту функцию в будущем выпуске. После создания конфигурации карты останутся на уровне узла, а не на уровне кластера.
Пока вы создаете распределенную карту прямо из конфигурации, используете ее и уничтожаете, ваш подход должен работать без каких-либо проблем.