Infinispan自定义ConsistentHashFactory弃用后替代方案咨询

1. 原生共置能力与KeyAffinityService的重平衡问题 #

你对KeyAffinityService的判断是准确的，这个组件仅能生成可映射到指定节点的键值，不具备数据所有权的约束能力。集群触发重平衡时（不管是节点上下线、容量调整还是配置变更），默认一致性哈希逻辑会重新分配segment归属，哪怕原节点正常运行，原本归属它的segment也可能被划走，对应存量数据必然会迁移，KeyAffinityService完全无法拦截这个过程。
原生能实现「指定客户端写入的记录固定在指定节点作为主副本」诉求的公开特性有两个，都不需要自定义哈希逻辑：

• HOTROD客户端就近路由：如果客户端和Infinispan Server是同机房/同服务器部署，开启就近路由策略后，客户端会优先把请求发到位置最近的节点，但这个只是请求路由优先级优化，不绑定数据所有权，重平衡时数据依然会迁移。
• 固定分区缓存：可以提前在缓存配置中声明独立分区，将分区的主副本所有权固定绑定到指定节点，只要不手动修改分区配置，重平衡过程不会迁移这部分分区的数据。这是目前原生能力里最接近你诉求的方案，缺点是分区需要提前配置，不支持无限制动态新增。

2. ConsistentHashFactory弃用的后续安排 #

你看到的弃用标记是准确的，ConsistentHashFactory从13.0版本开始标记@Deprecated，14.0版本会正式移除，官方没有提供同层级的公开替代扩展接口。
背后的原因是Infinispan从12版本开始重构了分布式数据分布逻辑，将segment分配、所有权切换、重平衡触发的全部逻辑收拢到内核DistributionManager模块内部，不再对外开放自定义segment到节点映射的SPI。官方给出的说明是，之前开放这个扩展点时，大量用户自定义的哈希逻辑存在缺陷，很容易破坏重平衡一致性，引发数据丢失、脑裂等严重问题，因此从稳定性角度将这部分能力收归内部实现，不再建议用户自定义修改。

3. 定制键节点映射、就近共置的可行落地路径 #

你的需求不属于Infinispan设计层面优先鼓励的场景——Infinispan的分布式设计初衷是让数据在集群内均匀分布，避免单节点负载倾斜，但依然有可稳定落地的实现方案，分版本选择即可：

• 如果你使用14.0之前的版本（12.x、13.x）：可以继续使用自定义KeyPartitioner+ConsistentHashFactory的组合实现，注意实现时要保证segment数量、节点所有权计算逻辑和官方默认实现对齐，避免重平衡时出现数据丢失，这个路径在14之前的版本可正常运行，只是官方不提供对应技术支持。
• 如果要适配14.0及以后的版本：不要尝试魔改内核哈希逻辑，推荐用键分组+容量因子约束的方案：自定义KeyPartitioner把需要共置到同一节点的键全部映射到固定的segment段，然后通过缓存配置的capacityFactor参数，给目标节点设置对应segment段的正容量因子，其余节点对应segment的容量因子设为0。重平衡过程中segment只会分配给容量因子大于0的节点，只要不修改容量因子配置，segment的主节点就不会漂移到其他节点，这个方案用到的都是14版本保留的公开配置和SPI，不会依赖弃用接口。

如果你的核心诉求是降低客户端访问延迟，优先选择官方就近路由+客户端近缓存的方案，稳定性远高于强行绑定数据主节点的实现，也不会破坏集群本身的容错能力。 #

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