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