Redis有序集合场景下如何实现ZSCAN命令的不区分大小写匹配？

• ZSCAN命令的MATCH参数是基于字节级的通配匹配，遵循与Shell通配一致的fnmatch规则，本身无内置大小写忽略能力，严格按照存储的字符串字节做比对。因此用*royal*匹配时，自然无法命中成员值里存的首字母大写的Royal条目。
• 你当前执行的查询命令还存在一个易忽略的笔误：写入测试数据时用的集合名是PLACES，但ZSCAN查询的是LOCATION_TRENDING集合，就算大小写匹配规则没有问题，也会因为查错集合返回空结果。

方案1：存储层维护小写映射副本（适合数据量较大、高频搜索的场景） #

• 逻辑设计：在原有PLACES集合保留原始展示值的基础上，新增一个专门用于搜索的有序集合PLACES_SEARCH，集合内的成员全部为对应地点名的全小写形式，分数与原集合完全同步。
• 写入示例：
  原写入命令ZADD PLACES 1 "The Clift Royal Sonesta Hotel"，同步追加执行：
  ZADD PLACES_SEARCH 1 "the clift royal sonesta hotel"
• 搜索流程：
  1. 把用户输入的搜索关键词同步转为全小写形式（比如输入Royal转为royal）
  2. 对PLACES_SEARCH执行ZSCAN匹配：ZSCAN PLACES_SEARCH 0 MATCH "*royal*" COUNT 100
  3. 把扫描到的小写匹配条目回查PLACES集合，拿到对应的原始展示名称返回给用户
• 注意事项：所有对PLACES集合的写入、修改、删除操作，必须同步更新PLACES_SEARCH集合，避免两侧数据不一致。

方案2：应用层扫描后本地过滤（适合数据量小于10万条的中小规模场景） #

• 逻辑设计：不额外维护存储副本，直接通过ZSCAN拉取目标集合的全量成员，在业务代码层做大小写不敏感的包含判断，跳过逐字节匹配的大小写限制。
• 实现参考：业务代码中拿到扫描返回的成员值后，统一将成员值和搜索关键词都转为全小写/全大写，再做字符串包含判断，完全规避大小写差异带来的匹配遗漏。
• 优势：省去了双集合的一致性维护成本，对于十万级以内的集合规模，ZSCAN的扫描性能和本地过滤的开销完全可以支撑业务需求。

方案3：依赖Redis模块能力实现（适合具备Redis Stack部署环境的场景） #

• 如果环境支持RediSearch模块，可以直接为PLACES集合创建文本索引，配置索引时开启大小写不敏感的分词匹配规则，搜索时直接通过模块查询接口获取匹配结果，无需手动维护副本或做本地过滤。

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