Hazelcast Near Cache не контролируется Split Brain Protection(кворум)

Question

Я использовал встроенный hazelcast 4.0.1 в проекте весенней загрузки для управления кешем проекта. Я установил Near Cache, а также установил функцию защиты разделения мозга, которая до 4.0 называлась Quorum.

Однако я обнаружил проблему. Например, я помещаю операцию кеширования в службу:

@Cacheable(value ="CacheSpaceName", key ="#id")
public String findById(String id) {
   ...
}

Если правильные данные были кэшированы в Near Cache, даже если действует защита с разделенным мозгом, служба все равно будет возвращать правильный результат, а не будет отклонена защитой с разделенным мозгом.

Как сделать так, чтобы Near Cache также контролировался с помощью Split Brain Protection? Я надеюсь, что когда происходит разделение мозга, маленькие кластеры не могут нормально работать, и только большие кластеры могут нормально работать.

Ниже приведен код конфигурации ближнего кеша и конфигурации защиты разделения мозга в проекте:

final NearCacheConfig nearCacheConfig = new NearCacheConfig()
  .setInMemoryFormat(InMemoryFOrmat.OBJECT)
  .setCacheLocalEntries(true)
  .setMaxIdleSeconds(xxx);

MapConfig allMapConfig = new MapConfgi.setName("*").setNearCacheConfig(nearCacheConfig)
  .setBackupCount(0).setMaxIndleSeconds(xxx).setInMemoryFormat(InMemoryFormat.OBJECT)
  .setMergePolicyConfig(xxx)

final SplitBrainProtectionConfig splitBrainProtectionConfig = new SplitBrainProtectionConfig("name", true, 2);
splitBrainProtectionConfig.setProtectOn(SplitBrainProtectionOn.READ_WRITE);

allMapConfig.setSplitBrainProtectionName("name");
config.addSplitBrainProtectionConfig(splitBrainProtectionConfig);
config.addMapConfig(allMapConfig);

Answer 1

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

Аналогичная конфигурация "минимального числа участников" существует и в функции защиты разделенного мозга Hazelcast. Когда Hazelcast обнаруживает, что текущее количество членов кластера меньше этого значения, определенные функции кэширования кластера запрещаются. Но поскольку это всего лишь ограничение операции с кешем, и я обнаружил, что кешем NearCache нельзя управлять, у меня есть вопрос. Хотя позже было обнаружено, что разделенная защита мозга Хейзелкаста может совсем не соответствовать моим потребностям.

Но теперь я нашел другой способ удовлетворить свои потребности. Фактически, это использование фильтра для проверки минимального количества членов. Функция защиты разделенного мозга Hazelcast больше не нужна (в настоящее время она все еще нужна для восстановления разделенного мозга, поэтому стратегия слияния также настроена нормально).

Answer 2

NearCache не покрывается защитой Split Brain, поскольку NearCache - это кэширование на стороне приложения, а встроенная защита Hazelcast предназначена для защиты членов кластера (серверов).

В дополнение к вашей точке -

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

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