Hazelcast, сохраняющий и загружающий данные на всех узлах - PullRequest
Новая
       131

Hazelcast, сохраняющий и загружающий данные на всех узлах

0 голосов
/ 24 апреля 2020

У меня есть настройка распределенного кэша с настройкой 2 узлов, которая требует настройки постоянства для обоих участников.

У меня реализованы MapSore и Maploader, и один и тот же код развернут на обоих узлах.

MapStore и MapLoader работают абсолютно нормально на установке с одним участником, но после присоединения другого участника MapStore и Maploader продолжают работать на первом члене, и все вставки или обновления, выполняемые вторым участником, сохраняются на диске через первый член

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

Есть ли параметр, который я могу изменить для достижения этого.

Вот моя конфигурация Hazlecast Spring. 

@Bean
    public HazelcastInstance hazelcastInstance(H2MapStorage h2mapStore) throws IOException{
        MapStoreConfig mapStoreConfig = new MapStoreConfig();
        mapStoreConfig.setImplementation(h2mapStore);
        mapStoreConfig.setWriteDelaySeconds(0);
        YamlConfigBuilder configBuilder=null;

        if(new File(hazelcastConfiglocation).exists()) {
            configBuilder = new YamlConfigBuilder(hazelcastConfiglocation);
        }else {
            configBuilder = new YamlConfigBuilder();
        }
        Config config = configBuilder.build();
        config.setProperty("hazelcast.jmx", "true");
        MapConfig mapConfig = config.getMapConfig("requests");
        mapConfig.setMapStoreConfig(mapStoreConfig);

        return Hazelcast.newHazelcastInstance(config);
    }

Вот моя конфигурация hazlecast yml - она ​​помещена в /opt/hazlecast.yml, которая подобрана моей конфигурацией пружины выше . 

hazelcast:
    group:
      name: tsystems
    management-center:
      enabled: false
      url: http://localhost:8080/hazelcast-mancenter
    network:
      port:
        auto-increment: true
        port-count: 100
        port: 5701
      outbound-ports:
        - 0
      join:
        multicast:
          enabled: false
          multicast-group: 224.2.2.3
          multicast-port: 54327
        tcp-ip:
          enabled: true
          member-list:
            - 192.168.1.13

Полный код доступен здесь: [https://bitbucket.org/samrat_roy/hazelcasttest/src/master/] [1]

Ответы [ 2 ]

0 голосов
/ 24 апреля 2020

Хорошо, после долгих попыток, я заметил крошечную крошечную критическую деталь покупки.

Хранилище данных должно быть централизованной системой, доступной для всех участников Hazelcast. Постоянство в локальной файловой системе не поддерживается.

Это абсолютно соответствует тому, что я наблюдал [https://docs.hazelcast.org/docs/latest/manual/html-single/#loading -and-store-persistent-data]

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

    @Component
public class HazelCastEntryListner
        implements EntryAddedListener<String,Object>, EntryUpdatedListener<String,Object>, EntryRemovedListener<String,Object>,
        EntryEvictedListener<String,Object>, EntryLoadedListener<String,Object>, MapEvictedListener, MapClearedListener {


    @Autowired
    @Lazy
    private RequestDao requestDao;

Я создал этот класс и подключил его к конфигурации следующим образом: 

MapConfig mapConfig = config.getMapConfig("requests");
        mapConfig.addEntryListenerConfig(new EntryListenerConfig(entryListner, false, true));
        return Hazelcast.newHazelcastInstance(config);

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

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

Я не использую Hazelcast в качестве кэша, скорее я использую в качестве механизма синхронизации данных.

0 голосов
/ 24 апреля 2020

Это может быть просто неудача и малые объемы данных, а не фактическая ошибка.

На каждом узле попробуйте запустить метод localKeySet () и распечатать результаты.

Это скажет вам, какие ключи находятся на каком узле в кластере. Узел, которому принадлежит ключ " X ", вызовет хранилище карт для этого ключа, даже если обновление было инициировано другим узлом.

Если у вас мало объемов данных, это может быть не так разделение данных 50/50. В крайнем случае 2 записи данных в кластере с двумя узлами могут иметь обе записи данных на одном и том же узле. Если у вас есть 1000 записей данных, маловероятно, что они все будут находиться на одном и том же узле.

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

...