Redis集群模式下SORT命令中特殊字符的优化处理

在Redis 7.4版本中，当在集群模式下使用SORT命令时，如果GET选项使用了特殊字符#，会导致一个意外的错误。本文将深入分析这个问题的原因以及解决方案。

问题背景

Redis的SORT命令是一个非常强大的功能，它允许对列表、集合或有序集合中的元素进行排序，并且可以通过GET选项获取关联的数据。在集群模式下，Redis要求所有通过GET选项访问的键必须与排序的原始键位于同一个哈希槽中，这是为了确保集群数据分片的正确性。

问题现象

在Redis 7.4集群环境中，当执行类似以下的命令时：

SORT mylist BY {mylist}price_* GET {mylist}price_* GET #

系统会返回错误：

ERR GET option of SORT denied in Cluster mode when keys formed by the pattern may be in different slots.

问题分析

这个问题的根源在于Redis集群模式下对SORT命令GET选项的严格检查。Redis会对所有GET选项中的键模式进行哈希槽计算，并与原始键的哈希槽进行比较。然而，特殊字符#在SORT命令中有特殊含义，它表示返回被排序元素本身的值，而不是从其他键获取数据。

当前的实现没有区分普通键模式和特殊字符#，导致即使使用#也会触发哈希槽检查，从而产生错误。

解决方案

修复方案是在进行哈希槽检查时，增加对特殊字符#的识别。具体来说，当GET选项的值为#时，应该跳过哈希槽检查，因为#并不代表一个实际的键。

代码修改位于sort.c文件中，在哈希槽比较逻辑前增加对#字符的特殊处理：

if (server.cluster_enabled && 
    patternHashSlot(c->argv[j+1]->ptr, sdslen(c->argv[j+1]->ptr)) != getKeySlot(c->argv[1]->ptr) && 
    strcasecmp(c->argv[j+1]->ptr,"#")) {
    // 原有错误处理逻辑
}

技术意义

这个优化不仅修复了一个功能性问题，更重要的是：

1. 保持了Redis集群模式下数据分片的完整性原则
2. 正确处理了SORT命令中特殊字符的语义
3. 确保了向后兼容性，不影响现有合法使用场景

总结

Redis作为分布式系统，在集群模式下需要严格保证数据访问的正确性。这个问题的修复展示了Redis开发团队对细节的关注，以及在保证集群安全性的同时，正确处理特殊用例的能力。对于开发者而言，理解这些底层机制有助于更好地使用Redis的强大功能。