Redis存储可重复(name,number)二元组并支持数值范围检索的最优方案及现有实现合理性

这个方案能跑通核心逻辑，但实际落地时会碰到几个明显的设计问题：

• 冗余存储浪费内存：为了绕开Sorted Set成员不能重复的限制，每条记录都要拼一段唯一ID当成员值，等于凭空给每条记录加了一截需要持久化的无效字符串。重复记录越多，这部分无意义的内存开销就越大——比如存1万条完全相同的(“测试账号”, 100)，就得生成1万个不同的ID前缀塞进去，纯纯占用Redis内存。
• 增加额外的查询解析成本：不管是按分数范围拉取结果，还是后续做数据统计、业务关联，都得先把每条返回的成员字符串按分隔符切开，剥掉前面的ID部分才能拿到真实的name值，每次查询都多了一步完全没必要的字符串处理。
• 操作精度不足：如果后续需要删除某一条指定的重复记录，因为Redis端存的是带ID的成员值，要是业务侧没额外存一份“ID-原始记录”的映射，根本没法精准定位要删的是哪个成员，只能先按分数范围扫出所有命中的记录、逐行拆分校验才能找到目标，操作效率极低。
• 结构维护成本偏高：Sorted Set底层是跳表+哈希表结构，当成员量涨到百万级以上，插入、删除时的跳表重平衡开销会随成员数线性上涨。把所有重复记录拆成独立成员塞进Sorted Set，本来可以按相同score聚合的内容被拆成大量冗余条目，结构维护成本远高于实际业务需要。

针对“支持完全重复记录存储、按number范围筛选”两个核心要求，没必要硬适配Sorted Set的成员唯一性限制，有更省心的实现方式：

• 原生结构组合方案（无额外依赖，所有Redis版本均可使用）
  把逻辑拆成两层实现：
  1. 单独建一个Sorted Set做number值的范围索引，这个Sorted Set的成员就是真实的number取值，score也直接设成对应的number值，不需要加任何冗余前缀。
  2. 把每个number对应的所有重复name记录，存在一个以rec:{number}为key的List结构里，重复的name直接往List里追加就行，天然支持存储完全重复的记录。
     需要按number范围查数据时，直接用ZRANGEBYSCORE拿到所有落在目标区间的number值，再遍历拿对应List里的所有记录即可。这种实现不需要生成额外的唯一ID，没有冗余存储，拿到的查询结果可以直接用，删除单条记录也能精准定位到对应number的List做操作，整体效率远高于之前的单Sorted Set方案。
• 模块扩展方案
  如果Redis环境加载了RediSearch模块，可以直接把每条(name, number)记录存成独立文档，给number字段建立数值范围索引，不仅能支持要求的重复记录存储、范围筛选能力，还能灵活扩展组合条件查询的需求，灵活度更高。

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