Spring Boot+RedisHash多索引下Redis Cluster的CROSSSLOT错误解决

问题原因 #

调用findBySessionIdAndTransactionId时，Spring Data Redis会执行sinter命令求两个索引集合的交集：corp:TransactionDetails:sessionId:xxx和corp:TransactionDetails:transactionId:xxx。但Redis Cluster通过键的哈希值分配槽位，这两个键的哈希结果不同，导致它们落在不同槽位，而Redis Cluster不允许跨槽执行集合交集这类命令，因此抛出CROSSSLOT错误。

解决方案 #

1. 用哈希标签强制所有相关键落在同一槽位 #

修改@RedisHash的value，加入Redis哈希标签（大括号包裹的内容），Redis会仅对大括号内的字符串计算哈希值，确保该实体的所有关联键（实体本身、索引键）都落在同一个槽位。

修改后的实体类：

@RedisHash(value = "{corp:TransactionDetails}", timeToLive = Constants.TIME_TO_LIVE_REDIS)
public class TransactionDetailsEntity {
    private static final long serialVersionUID = 1L;
    @Id
    @Indexed
    private UUID transactionId;
    @Indexed
    private String sessionId;
    @Indexed
    private String referenceNumber;
    // 其他字段保持不变
}

注意事项：

• 所有该实体的键（如{corp:TransactionDetails}:xxxx-xxxx、{corp:TransactionDetails}:sessionId:xxxx）都会基于corp:TransactionDetails计算哈希，确保同槽。
• 这种方式会让该实体的所有数据集中在一个槽位，可能影响集群负载均衡，适合数据量不大的场景，或你能接受该槽位的负载压力。
• 若已有存量数据，需重新写入以生成带哈希标签的键，否则旧键仍在原槽位，查询仍会报错。

2. 自定义索引键生成规则 #

如果不想让所有实体键集中在一个槽，可自定义索引键的生成逻辑，给每个索引键添加相同的哈希标签。

实现IndexResolver接口改写索引键格式，让索引键以{corp:TransactionDetails}:开头，确保哈希计算基于同一内容：

@Component
public class CustomIndexResolver extends SimpleIndexResolver {

    private static final String HASH_TAG_PREFIX = "{corp:TransactionDetails}:";

    public CustomIndexResolver(RedisMappingContext mappingContext) {
        super(mappingContext);
    }

    @Override
    public Set<RedisKey> resolveIndexes(String keyspace, Object value) {
        Set<RedisKey> indexes = super.resolveIndexes(keyspace, value);
        return indexes.stream()
                .map(key -> RedisKey.of(HASH_TAG_PREFIX + key.getKey().substring(keyspace.length() + 1)))
                .collect(Collectors.toSet());
    }
}

注意：需同步将@RedisHash的value设置为{corp:TransactionDetails}，确保实体键和索引键的哈希计算依据一致。

3. 应用层过滤（折中方案） #

如果集群负载均衡要求较高且数据量不大，可以先通过单个索引查询结果，再在应用层过滤另一条件。比如先查sessionId匹配的所有记录，再筛选出transactionId符合的条目：

// 在Repository中新增单索引查询方法
List<TransactionDetailsEntity> findBySessionId(String sessionId);

// 业务代码中做过滤
List<TransactionDetailsEntity> candidates = transactionDetailsRepository.findBySessionId(sessionId);
Optional<TransactionDetailsEntity> result = candidates.stream()
        .filter(entity -> entity.getTransactionId().equals(uuid))
        .findFirst();

优缺点：无需修改Redis键结构，但如果单个索引返回数据量较大，会增加应用层内存消耗和处理时间，适合小数据量场景。

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