第 8 章 设置分区处理

在脑裂情形中，每个网络分区将安装自己的 JGroups 视图，从其他分区中删除节点。我们没有一种直接的方法来确定是否被分成两个或者多个分区，因为分区不能相互识别。相反，我们假设，当一个或多个节点从 JGroups 集群消失时，我们假设集群被分割，而无需发送显式保留消息。

如上一节所述，Data Grid 无法检测节点是否因为进程/机器崩溃而离开 JGroups 视图，或者由于网络故障：每当节点离开 JGroups 集群时，它假定是因为网络问题而离开的。

如果配置的副本数(numOwners)大于 1，集群可以保持可用，并将尝试在崩溃的节点上生成新数据副本。但是，其他节点可能会在重新平衡过程中崩溃。如果超过 numOwners 节点在较短的时间内崩溃，则一些缓存条目可能会完全从集群消失。在这种情况下，在启用了 DENY_READ_WRITES 或 ALLOW_READS 策略的情况下，Data Grid 假设（正确）有脑裂并进入 DEGRADED 模式，如 split-brain 部分所述。

管理员也可以快速关闭多个 numOwners 节点，从而导致只存储在这些节点上的数据丢失。当管理员正常关闭节点时，Data Grid 知道节点无法返回。但是，如果这些节点崩溃，集群不会跟踪每个节点的保留方式，缓存仍然进入 DEGRADED 模式。

在这个阶段，集群无法恢复其状态，除了在使用外部源的数据重启时停止和禁止它。集群应该配置有适当的 numOwners，以避免 numOwners 成功节点失败，因此这种情况应该非常罕见。如果应用程序可以在缓存中处理一些数据，管理员可以通过 JMX 将可用性模式强制返回到 AVAILABLE。

冲突管理器是一个允许用户检索给定键的所有存储副本值的工具。除了允许用户处理存储副本有冲突值的缓存条目的流外。另外，通过利用 EntryMergePolicy 接口的实现，可以自动解析冲突。

在分区合并过程中，ConflictManager 会自动尝试解决配置的 EntryMergePolicy 冲突，但也可以手动搜索应用程序所需的/解析冲突。

以下代码演示了如何检索 EmbeddedCacheManager 的 ConflictManager，如何检索给定密钥的所有版本以及如何检查给定缓存中的冲突。

EmbeddedCacheManager manager = new DefaultCacheManager("example-config.xml");
Cache<Integer, String> cache = manager.getCache("testCache");
ConflictManager<Integer, String> crm = ConflictManagerFactory.get(cache.getAdvancedCache());

// Get All Versions of Key
Map<Address, InternalCacheValue<String>> versions = crm.getAllVersions(1);

// Process conflicts stream and perform some operation on the cache
Stream<Map<Address, CacheEntry<Integer, String>>> conflicts = crm.getConflicts();
conflicts.forEach(map -> {
   CacheEntry<Integer, String> entry = map.values().iterator().next();
   Object conflictKey = entry.getKey();
   cache.remove(conflictKey);
});

// Detect and then resolve conflicts using the configured EntryMergePolicy
crm.resolveConflicts();

// Detect and then resolve conflicts using the passed EntryMergePolicy instance
crm.resolveConflicts((preferredEntry, otherEntries) -> preferredEntry);

除非缓存是分布式或复制的，否则分区处理配置将被忽略。默认分区处理策略是 ALLOW_READ_WRITES，默认的 EntryMergePolicy 是 MergePolicies::PREFERRED_ALWAYS。

<distributed-cache name="the-default-cache">
   <partition-handling when-split="ALLOW_READ_WRITES" merge-policy="PREFERRED_NON_NULL"/>
</distributed-cache>

以编程方式实现相同的：

ConfigurationBuilder dcc = new ConfigurationBuilder();
dcc.clustering().partitionHandling()
                    .whenSplit(PartitionHandling.ALLOW_READ_WRITES)
                    .mergePolicy(MergePolicy.PREFERRED_ALWAYS);

<distributed-cache name="mycache">
   <partition-handling when-split="ALLOW_READ_WRITES"
                       merge-policy="org.example.CustomMergePolicy"/>
</distributed-cache>

ConfigurationBuilder dcc = new ConfigurationBuilder();
dcc.clustering().partitionHandling()
                    .whenSplit(PartitionHandling.ALLOW_READ_WRITES)
                    .mergePolicy(new CustomMergePolicy());

public class CustomMergePolicy implements EntryMergePolicy<String, String> {

   @Override
   public CacheEntry<String, String> merge(CacheEntry<String, String> preferredEntry, List<CacheEntry<String, String>> otherEntries) {
      // decide which entry should be used

      return the_solved_CacheEntry;
   }

# list all necessary implementations of EntryMergePolicy with the full qualified name
org.example.CustomMergePolicy

缓存的可用性模式在 JMX 中作为 Cache MBean 的属性公开。该属性是可写的，允许管理员强制将缓存从 DEGRADED 模式强制迁移到 AVAILABLE （一致性成本）。

可用性模式也可以通过 AdvancedCache 接口访问：

AdvancedCache ac = cache.getAdvancedCache();

// Read the availability
boolean available = ac.getAvailability() == AvailabilityMode.AVAILABLE;

// Change the availability
if (!available) {
   ac.setAvailability(AvailabilityMode.AVAILABLE);
}