3.3. 分布式缓存

容量因素根据节点可用的资源分配片段到节点的映射。

要配置容量因素，您可以指定任何非负数，Data Grid 哈希算法会为每个节点分配一个负载因其容量因子（作为主要所有者和备份所有者）权重。

例如，nodeA 在同一 Data Grid 集群中有 2 倍的内存，它比 nodeB 可用。在这种情况下，将 capacityFactor 设置为 2 的值，将 Data Grid 配置为将片段数量分配给 nodeA。

可以设置容量因数 0， 但仅在节点没有加入集群时，才有足够长以有用的数据所有者。

提示在传输级别配置：

<transport
    cluster="MyCluster"
    machine="LinuxServer01"
    rack="Rack01"
    site="US-WestCoast" />

以下代码片段描述了如何获取和使用对此服务的引用。

// 1. Obtain a reference to a cache
Cache cache = ...
Address address = cache.getCacheManager().getAddress();

// 2. Create the affinity service
KeyAffinityService keyAffinityService = KeyAffinityServiceFactory.newLocalKeyAffinityService(
      cache,
      new RndKeyGenerator(),
      Executors.newSingleThreadExecutor(),
      100);

// 3. Obtain a key for which the local node is the primary owner
Object localKey = keyAffinityService.getKeyForAddress(address);

// 4. Insert the key in the cache
cache.put(localKey, "yourValue");

服务在第 2 步中启动：此时，它使用提供的 Executor 生成和队列密钥。在第 3 步中，我们从服务获取一个密钥，并在第 4 步中使用它。

KeyAffinityService 扩展了 生命周期，允许停止和（重新）启动它：

public interface Lifecycle {
   void start();
   void stop();
}

该服务通过 KeyAffinityServiceFactory 进行实例化。所有工厂方法都有一个 Executor 参数，该参数用于异步密钥生成（因此它不会在调用者的线程中发生）。用户负责处理此可执行文件的关机 。

启动后，需要明确停止 KeyAffinityService。这会停止后台密钥生成，并释放其他持有的资源。

KeyAffinityService 本身停止的唯一情形是注册它的缓存管理器关闭的唯一情况。

当缓存拓扑更改时（例如节点加入或离开集群），KeyAffinityService 生成的密钥的所有权可能会改变。密钥关联性服务跟踪这些拓扑更改，且不会返回当前映射到不同节点的键，但不会对之前生成的密钥进行任何操作。

因此，应用程序应完全将 KeyAffinityService 视为优化，它们不应依赖生成的密钥的位置进行正确的性。

特别是，应用程序不应依赖 KeyAffinityService 生成的密钥来始终放在同一地址。密钥共存仅由 Grouping API 提供。

对 Key affinity 服务 的补充，分组 API 允许您在同一节点上并置一组条目，但无法选择实际节点。

默认情况下，使用键的 hashCode （） 计算密钥片段。如果使用 grouping API，Data Grid 将计算组的片段，并用作密钥的片段。有关如何将段映射到节点的更多详细信息，请参阅 Key Ownership 部分。

在使用组 API 时，每个节点仍然可以计算每个密钥的所有者，而无需联系其他节点。因此，无法手动指定组。组可以涉及条目（由密钥类生成）或 extrinsic （由外部功能生成）。

首先，您必须启用组。如果您要以编程方式配置数据网格，请调用：

Configuration c = new ConfigurationBuilder()
   .clustering().hash().groups().enabled()
   .build();

或者，如果您使用 XML：

<distributed-cache>
   <groups enabled="true"/>
</distributed-cache>

如果您掌控了关键类（您可以修改类定义，它不是不可修改库的一部分），我们建议使用内部组。内部组通过将 @Group 注释添加到方法来指定。我们来看一个例子：

class User {
   ...
   String office;
   ...

   public int hashCode() {
      // Defines the hash for the key, normally used to determine location
      ...
   }

   // Override the location by specifying a group
   // All keys in the same group end up with the same owners
   @Group
   public String getOffice() {
      return office;
   }
   }
}

如果您没有对密钥类进行控制，或者组的确定是键类的不当问题，我们建议使用 extrinsic 组。通过实施 Grouper 接口来指定 extrinsic 组。

public interface Grouper<T> {
    String computeGroup(T key, String group);

    Class<T> getKeyType();
}

如果为同一键类型配置了多个 Grouper 类，则调用它们的所有类，接收上一个键计算的值。如果键类也具有 @Group 注释，则第一个 Grouper 将接收被注释的方法计算的组。这可让您在使用内部组时对组进行更大的控制。让我们来看看一个 Grouper 实现示例：

public class KXGrouper implements Grouper<String> {

   // The pattern requires a String key, of length 2, where the first character is
   // "k" and the second character is a digit. We take that digit, and perform
   // modular arithmetic on it to assign it to group "0" or group "1".
   private static Pattern kPattern = Pattern.compile("(^k)(<a>\\d</a>)$");

   public String computeGroup(String key, String group) {
      Matcher matcher = kPattern.matcher(key);
      if (matcher.matches()) {
         String g = Integer.parseInt(matcher.group(2)) % 2 + "";
         return g;
      } else {
         return null;
      }
   }

   public Class<String> getKeyType() {
      return String.class;
   }
}

grouper 实现必须在缓存配置中显式注册。如果您要以编程方式配置数据网格：

Configuration c = new ConfigurationBuilder()
   .clustering().hash().groups().enabled().addGrouper(new KXGrouper())
   .build();

或者，如果您使用 XML：

<distributed-cache>
   <groups enabled="true">
      <grouper class="com.acme.KXGrouper" />
   </groups>
</distributed-cache>

AdvancedCache 有两个特定于组的方法：

两种方法都会迭代整个数据容器和存储（如果存在），因此当缓存包含大量小组时，它们可能会很慢。