4. Redis索引基础：Redis中索引的概念、Hash与Sorted Set实现简单索引、索引的存储与查询开销
4.1 Redis中的索引概念
在传统关系型数据库中，索引是一种独立于数据表存储的辅助数据结构，用于加速数据检索。在Redis中，索引的概念有所不同：Redis本身是一个键值存储系统，其主键（Key）就是天然的一级索引。然而，当我们需要根据非主键字段（如用户ID、任务状态、时间戳）进行快速查找时，就需要借助Redis的数据结构来构建二级索引。
核心认知： Redis的索引本质上是以空间换时间的工程实践。通过预先将查询条件映射到特定的Key或有序集合中，将原本需要全量扫描的O(N)操作降级为O(log N)甚至O(1)的查找。
Redis索引的常见实现方式包括：
- Hash索引： 利用Hash的field作为索引列，value作为被索引的实体ID或完整数据，适用于等值查询场景。
- Sorted Set索引： 利用Sorted Set的score作为排序字段，member作为被索引的实体ID，适用于范围查询、排序、分页场景。
- Set索引： 利用Set的成员去重特性，适用于标签、分类、集合归属查询。
- List索引： 利用List的有序性，适用于简单队列、时间线场景（但查询效率较低）。
| 索引类型 | 底层数据结构 | 查询复杂度 | 典型场景 |
|---|---|---|---|
| Hash索引 | Hash Table | O(1) | 用户信息、配置项、任务状态 |
| Sorted Set索引 | Skip List + Hash Table | O(log N) | 排行榜、时间范围查询、延迟队列 |
| Set索引 | Hash Table | O(1) | 标签系统、去重集合、权限组 |
| List索引 | Linked List | O(N) | 消息队列、简单时间线 |
4.2 使用Hash实现简单索引
Hash结构非常适合构建一对一或多对一的索引关系。例如，在消息队列的去重场景中，我们需要根据任务ID快速判断任务是否已被处理过。
示例：任务去重索引
# 构建索引：将任务ID映射到处理状态
HSET task:processed:index "task_20250321_001" "processed"
HSET task:processed:index "task_20250321_002" "pending"
HSET task:processed:index "task_20250321_003" "processed"
# 查询任务是否已处理
HEXISTS task:processed:index "task_20250321_001" # 返回1，表示已存在
# 批量查询
HMGET task:processed:index "task_20250321_001" "task_20250321_002"
# 返回: 1) "processed" 2) "pending"
设计要点： Hash索引的Key命名建议采用
业务域:索引类型:索引名称 的格式，如 task:processed:index。field存储被索引的实体ID，value存储与该索引相关的元数据（如状态、时间戳）。这种设计使得单个Hash可以承载数百万个field，内存效率极高。
4.3 使用Sorted Set实现排序与范围索引
当我们需要对任务进行按时间排序、范围查询或分页时，Sorted Set是最佳选择。在消息队列的热Key治理中，Sorted Set常用于构建延迟队列和时间窗口去重。
示例：基于时间戳的任务索引
# 添加任务到时间索引，score为时间戳（毫秒）
ZADD task:time:index 1711000000000 "task_20250321_001"
ZADD task:time:index 1711000001000 "task_20250321_002"
ZADD task:time:index 1711000002000 "task_20250321_003"
# 查询某个时间范围内的任务
ZRANGEBYSCORE task:time:index 1711000000000 1711000001500
# 返回: 1) "task_20250321_001" 2) "task_20250321_002"
# 分页查询（按时间倒序）
ZREVRANGEBYSCORE task:time:index +inf -inf LIMIT 0 2
# 返回: 1) "task_20250321_003" 2) "task_20250321_002"
# 获取任务在索引中的排名（用于判断任务是否在窗口内）
ZRANK task:time:index "task_20250321_002"
# 返回: 1 (从0开始计数)
避坑指南： Sorted Set的score在Redis内部使用双精度浮点数存储。当score为时间戳时，建议使用毫秒级时间戳（13位整数），避免精度丢失。对于需要更高精度的场景，可以将时间戳与序列号组合（如
1711000000000.001），但需注意浮点数精度限制。
4.4 索引的存储与查询开销分析
理解索引的存储和查询开销，是设计高效Redis索引的前提。以下从内存占用和时间复杂度两个维度进行分析。
4.4.1 存储开销
| 索引类型 | 每元素内存开销（近似） | 主要内存消耗点 | 扩展性 |
|---|---|---|---|
| Hash索引 | ~60-80字节 | field字符串、value字符串、Hash表指针 | 百万级field表现良好 |
| Sorted Set索引 | ~120-160字节 | member字符串、score（8字节）、Skip List指针、Hash表指针 | 十万级member后内存增长明显 |
| Set索引 | ~50-70字节 | member字符串、Hash表指针 | 百万级member表现良好 |
优化建议： 当索引的field或member为长字符串（如UUID）时，建议先对原始ID进行哈希映射（如CRC32或MurmurHash），将长ID转换为短整数存储，可减少30%-50%的内存开销。但需注意哈希冲突的处理。
4.4.2 查询开销
不同索引类型在不同操作下的时间复杂度差异显著，直接影响热Key场景下的性能表现。
| 操作类型 | Hash索引 | Sorted Set索引 | Set索引 |
|---|---|---|---|
| 单点查询（等值） | O(1) | O(log N) | O(1) |
| 范围查询 | 不支持 | O(log N + M) | 不支持 |
| 插入/更新 | O(1) | O(log N) | O(1) |
| 删除 | O(1) | O(log N) | O(1) |
| 计数 | O(1)（HLEN） | O(1)（ZCARD） | O(1)（SCARD） |
注：M为返回的元素数量，N为索引中的总元素数量。
4.5 索引设计模式对比
在实际的消息队列热Key治理中，我们经常需要组合使用多种索引。以下对比两种常见的设计模式：
| 设计模式 | 数据结构组合 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| Hash + Sorted Set | Hash存储完整数据，Sorted Set存储排序索引 | 需要同时支持等值查询和范围排序 | 查询灵活，数据与索引分离 | 需要维护两份数据的一致性 |
| Sorted Set + Set | Sorted Set存储时间索引，Set存储状态索引 | 需要按时间和状态联合查询 | 支持多维度查询 | 联合查询需在应用层做交集 |
实战建议： 在消息队列去重场景中，推荐使用Hash索引作为主去重索引（O(1)查询），配合Sorted Set索引作为时间窗口清理索引（O(log N)范围删除）。这种组合既能保证去重的高性能，又能实现过期数据的批量清理。
4.6 索引设计的最佳实践
- 索引粒度控制： 避免为每个实体创建独立的Key，应使用Hash/Sorted Set的field/member机制将索引聚合到少数Key中，减少Key数量，降低Redis的元数据开销。
- 索引生命周期管理： 为索引设置合理的TTL或使用定期清理策略（如ZREMRANGEBYSCORE），防止索引无限膨胀导致内存溢出。
- 索引与数据分离： 索引中只存储实体ID或短标识符，完整数据存储在另一个Hash中。这样索引可以更紧凑，查询时通过ID二次获取数据。
- 避免热Key： 当单个索引Key的访问量超过10万QPS时，考虑使用索引分片（如将索引拆分为多个Hash，按ID哈希路由）来分散热点。
性能红线： 单个Sorted Set的member数量建议控制在1000万以内，超过此阈值后，ZADD和ZRANGEBYSCORE的延迟会显著上升（从微秒级升至毫秒级）。对于超大规模索引，建议使用Redis Cluster进行分片存储。