Ignite Thin客户端是否支持Affinity colocation亲和共置功能？

亲和共置对瘦客户端的支持 #

亲和共置是Ignite服务端缓存的核心能力，和客户端类型无关，Thin Client完全支持用AffinityKey实现按指定字段将同组数据路由到同一节点。你测不到getAll性能提升不是功能不支持，是配置和用法有问题。

现有代码的问题 #

• 泛型混乱：定义缓存时写的是ClientCache<AffinityKey<Long>, PaymentReceiptResponse>，实际put操作里亲和键传的是固定字符串"clientId"，getAll的时候key泛型又变成了AffinityKey<String>，类型不匹配会直接导致分区路由计算错误，数据根本不会按预期共置。
• 分区感知配置不完整：你虽然开了partitionAwarenessEnabled开关，但如果客户端地址列表只配了单个集群节点，或者服务端版本低于2.10，分区感知根本不会生效，所有请求都会先打到单个节点再做转发，自然看不到性能优化效果。
• 用法错误：AffinityKey构造函数的第二个参数是实际参与共置计算的业务值，不是字段名，你写死传"clientId"字符串的话，所有数据都会被路由到同一个分区，完全达不到按客户端ID分节点共置的效果。

可直接用的修正示例 #

瘦客户端配置 #

@Bean
ClientConfiguration igniteThinClientConfiguration(IgniteProperties igniteProperties) {
    ClientConfiguration clientConfiguration = new ClientConfiguration();
    clientConfiguration.setTimeout(igniteProperties.getTimeout());
    // 必须配置集群所有节点的完整地址列表，不要只配单节点
    clientConfiguration.setAddresses(igniteProperties.getAddresses());
    // 开启分区感知是瘦客户端直接路由请求到数据节点的前提
    clientConfiguration.setPartitionAwarenessEnabled(true);
    // 按需配置分区连接数，默认1即可满足大部分场景
    clientConfiguration.setConnectionsPerPartition(1);
    return clientConfiguration;
}

缓存配置 #

你原来的缓存配置没有问题，不需要额外加亲和共置相关的配置项，保持原样即可：

private static ClientCacheConfiguration cacheConfig(String cacheName, String cacheGroup, String dataRegion) {
    ClientCacheConfiguration cfg = new ClientCacheConfiguration();
    cfg.setName(cacheName);
    cfg.setCacheMode(CacheMode.PARTITIONED);
    cfg.setBackups(0);
    cfg.setExpiryPolicy(new TouchedExpiryPolicy(new Duration(TimeUnit.HOURS, 6)));
    cfg.setStatisticsEnabled(true);
    cfg.setDefaultLockTimeout(3000L);
    cfg.setGroupName(cacheGroup);
    cfg.setDataRegionName(dataRegion);
    return cfg;
}

读写操作写法 #

IgniteClient igniteClient = Ignition.startClient(igniteConfiguration);
// 泛型统一：AffinityKey的泛型参数为主键类型，这里主键是Long类型就统一用Long
ClientCache<AffinityKey<Long>, PaymentReceiptResponse> receiptCache = igniteClient.getOrCreateCache(cacheConfig(...));

// 写入示例：第二个参数传真实的客户端ID业务值，不要传字段名字符串
Long bizPrimaryKey = 123L;
String actualClientId = "client_001"; // 从业务数据中取实际的客户端ID
receiptCache.put(new AffinityKey<>(bizPrimaryKey, actualClientId), value);

// 批量查询示例：同一个actualClientId对应的所有key会落在同一节点，getAll请求会直接发往对应节点，无跨节点转发开销
Set<AffinityKey<Long>> queryKeys = /* 注意泛型和缓存定义保持一致 */;
Map<AffinityKey<Long>, PaymentReceiptResponse> result = receiptCache.getAll(queryKeys);

效果校验 #

配置修正后可以通过缓存自带的统计指标看getAll的平均耗时，正常情况下同客户端ID的批量查询耗时会比随机key查询低40%以上，也可以通过服务端请求日志确认请求是否直接打到了数据所在节点，没有发生转发。

内容的提问来源于stack exchange，提问作者Ramil Izmaylov