Сохраняет ли Hazelcast значения MultiMap в локальном экземпляре, когда резервное копирование отключено? - PullRequest
0 голосов
/ 07 марта 2019

Я настраиваю мультикарту Hazelcast без резервного копирования (специально):

    config.getMultiMapConfig(SESSIONS_MAP)
            .setBackupCount(0)
            .setAsyncBackupCount(0)
            .setValueCollectionType(MultiMapConfig.ValueCollectionType.SET);

Моя цель состоит в том, чтобы каждый экземпляр сохранял свои собственные значения в MultiMap, чтобы при исчезновении сервера эти значения терялись,Правильно ли указана выше конфигурация?

Пример: экземпляры сервера в сеансах пользователя узла кластера.Я хочу хранить пользователей в MultiMap, чтобы каждый пользователь физически хранился в локальном экземпляре, но другие экземпляры могут искать там, где существует пользовательский сеанс.При сбое сервера пользовательские сеансы исчезают, как и записи в MultiMap.[Пользователи на самом деле хранятся в комнатах, например MultiMap<roomId, Set<userId>>, где комната может охватывать несколько экземпляров.Если один экземпляр выйдет из строя, комната может выжить, но я хочу, чтобы пользователи текущего экземпляра также стали недоступными в MultiMap.]

Только если гарантировано выше: стоит ли при контролируемом завершении работыочистить локальные записи перед выключением, или дешевле просто сделать так, чтобы экземпляр исчез?

В руководстве по https://docs.hazelcast.org/docs/latest-dev/manual/html-single/index.html#configuring-multimap не ясно прописано, что на самом деле происходит (илиЯ слишком слеп, чтобы найти это).

Ответы [ 2 ]

1 голос
/ 07 марта 2019

Если вы установите число резервных копий на ноль, это означает, что каждая запись будет храниться только в одном разделе (первичном). Но это не значит, что раздел будет размещен на «локальном» узле кластера.

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

Поскольку вы упоминаете «локальный экземпляр», я предполагаю, что вы используете Hazelcast во встроенном режиме, и узлы кластера Hazelcast находятся на тех же серверах, на которых размещены «комнаты». Возможно, вы захотите настроить MembershipListener; этот прослушиватель будет уведомлен всякий раз, когда узел покидает кластер, и затем прослушиватель может удалить записи карты, относящиеся к сеансам пользователя, размещенным в комнатах на этом узле.

1 голос
/ 07 марта 2019

Это неправильный вариант использования распределенной системы на основе разделов. Когда вы храните в многораздельной распределенной структуре данных, такой как Map или MultiMap, вы не контролируете, в каком разделе будут храниться ваши данные значения ключа. Раздел хоста для ваших данных определяется последовательным алгоритмом хеширования, применяемым к ключу. Это относится как к операциям записи, так и к операциям чтения. А при включенном резервном копировании данные реплицируются в резервные разделы на каждом узле, поэтому данные могут быть восстановлены в случае сбоя узла.

Таким образом, в вашем случае вы даже не знаете, является ли конкретная запись действительно локальной для вашего экземпляра (если только вы вручную не записываете это сопоставление раздела ключей с помощью API Hazelcast). Вы ищете запись, надеясь, что она будет локальной для этого экземпляра, потому что вы выполнили операцию записи этой записи с того же узла, но в действительности эта запись может храниться в разделе в каком-то другом узле кластера.

Я считаю, что вы хотите NearCache , что, другими словами, также может рассматриваться как кэш L1 - локально для вашего приложения. Если вы теряете экземпляр приложения, вы теряете NearCache и недоступны с MultiMap. Но даже с NearCache вы никогда не получите «null» или «data not found», потому что NearCache в принципе загружает данные от владельца раздела (узла кластера), если данные не найдены в NearCache.

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

Надеюсь, это поможет.

...