Hazelcast Near Cache is not controlled by Split Brain Protection(Quorum)

Question

I used the embedded hazelcast 4.0.1 in the spring boot project to manage the cache of the project. I set up Near Cache, and also set up the split-brain protection function, which was called Quorum before 4.0.

However, I found a problem. For example, I put the cache operation on a service:

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

If the correct data has been cached in Near Cache, even if the split-brain protection is in effect, the service will still return the correct result instead of being rejected by the split-brain protection.

How can I make Near Cache also be controlled by Split Brain Protection? I hope that when split brain occurs, small clusters cannot operate normally, and only large clusters can operate normally.

The following is the near cache configuration and split-brain protection configuration code in the project:

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

The problem that I raised that NearCahce is not controlled by the brain protection function is that I hope that when the cluster has a split brain, the small cluster is prohibited from providing any services, and the large cluster can provide services normally. The reason for this demand is that some businesses rely on Hazelcast's cache synchronization function. We hope that the cache can be updated as needed at certain times to avoid using outdated data. If there is a split brain, the cache update cannot be performed in a complete cluster. Therefore, if the small cluster still provides services normally at this time, it is likely to provide wrong services.

There is also a similar "minimum number of members" configuration in the Hazelcast split-brain protection function. When Hazelcast detects that the current number of cluster members is less than this value, certain caching functions of the cluster are prohibited. But because it is only a restriction on the cache operation, and I found that the NearCache cache can't be controlled, I have my question. Although it was later discovered that Hazelcast's split-brain protection may not meet my needs at all.

But now I have found another way to achieve my needs. In fact, it is to use a filter to verify the minimum number of members. Hazelcast's split-brain protection function is no longer needed (currently it is still needed for split-brain recovery, so The merge strategy is also configured normally).

Answer 2

NearCache is not covered by Split Brain protection as NearCache is application side caching and Hazelcast built-in split brain protection is meant to protect cluster members(servers).

Additionally to your point -

I hope that when split brain occurs, small clusters cannot operate normally, and only large clusters can operate normally

In split brain clusters, both sides regardless of their sizes, work fine. Cluster size becomes relevant when network partitioning is resolved and the two sides are ready to merge. Hazelcast deploys a background task that periodically searches for split clusters. When a split is detected, the side that will initiate the merge process is decided. This decision is based on the cluster size; the smaller cluster, by member count, merges into the bigger one. If they have an equal number of members, then a hashing algorithm determines the merging cluster. When deciding the merging side, both sides ensure that there’s no intersection in their member lists.