基于 GeminiDB Redis 实现 IM 聊天记录 SCAN 查询秒级转毫秒级优化
背景
即时通讯（IM）系统通常由接入层、消息服务、消息同步、消息存储、消息检索等模块组成。其中，历史消息查询直接影响用户打开会话、上拉聊天记录、跨端消息漫游等体验。IM消息系统需要同时满足消息同步、消息存储和消息检索能力；在数据规模持续增长后，存储层还需支撑海量数据、低成本存储、生命周期管理、高写入吞吐和低延迟读取。
部分实现中，聊天记录会按照“单条消息一个Key”的方式存储。以下示例以会话ID c10086 为例；在多租户场景下，可将 tenantId 与 conversationId 组合作为会话的唯一标识。 例如：
im:msg:{tenantId}:{conversationId}:{msgId} -> messageBody 查询某个会话的历史消息时，业务通过 SCAN MATCH 命令按Key前缀查找消息Key，再批量读取消息内容。
- 按会话前缀扫描消息Key的命令如下：
SCAN 0 MATCH im:msg:t001:c10086:* COUNT 1000
- 根据扫描得到的Key批量读取消息内容：
MGET im:msg:t001:c10086:m001 im:msg:t001:c10086:m002 im:msg:t001:c10086:m003
该方案实现简单，适合在消息规模较小、查询频率较低的阶段使用。但随着会话数量、消息数量和数据保留周期的增加，线上历史消息查询的耗时会逐步升高，部分场景下可能从几十毫秒攀升至秒级，并伴随P95、P99的抖动。
GeminiDB Redis 基于云原生分布式架构，兼容 Redis 协议，支持 String、Hash、ZSet、Stream 等主流数据结构及 SCAN 等常用命令。对于 IM 系统而言，这意味着业务侧无需改造即可沿用成熟的 Redis 生态，同时获得具备长期数据承载能力的分布式存储底座。
本文以此类“通过 SCAN MATCH 按会话前缀查找聊天记录”的场景为例，介绍在使用 GeminiDB Redis 后的推荐数据模型和查询方式，并说明如何通过分区并行 SCAN 来提升后台任务的处理效率。
使用场景
- IM 历史消息查询通过 SCAN MATCH 指令基于会话前缀匹配 Key。
- Redis 中消息 Key 总量庞大，查询性能受全局 Key 数量显著影响，导致检索耗时增加。
问题分析
SCAN 命令机制与限制
SCAN 是一种基于游标（Cursor）的增量迭代命令。遍历过程从 cursor=0 开始，直至服务端再次返回 0 结束。COUNT 表示本次迭代的工作量提示，不保证每次返回固定数量元素。SCAN 也可能返回重复元素，客户端需要具备幂等处理能力。
IM 消息查询场景分析
在IM聊天记录查询场景中，业务通常需要读取某个会话下的一段有序消息。例如：
conversationId = c10086 lastSeq = 123456 pageSize = 20
若使用 SCAN MATCH im:msg:t001:c10086:* 时，服务端需要在Key空间中增量遍历，再根据 MATCH 条件返回匹配 Key。
性能瓶颈
随着 Redis 全局 Key 数量激增，单个会话 Key 在总空间中的占比急剧下降。这意味着服务端需要遍历更多无关 Key 才能命中目标数据，导致查询耗时与全局 Key 规模呈正相关，严重拖慢响应速度。
该链路的主要耗时来自多轮 SCAN 网络往返、Key 空间遍历、MATCH 过滤、消息体读取，以及客户端排序和去重。对于高频历史消息查询，这类扫描型访问路径会放大实例 Key 规模对接口时延的影响。
方案介绍
本方案采用“消息体与索引分离”的双层存储架构，旨在平衡数据完整性与查询性能：
- 数据分层存储：
消息体数据层：持久化存储完整的消息内容，涵盖发送人、时间戳、消息类型、正文及扩展字段等元数据。
会话索引层：仅维护会话内的消息顺序映射（如消息序号或 Key），作为快速定位分页数据的“导航图”。
- 查询流程优化：
在线业务查询：采用“先索引后数据”的两步法。首先通过会话索引快速计算出目标页码对应的消息序号或 Key，随后批量读取对应的消息体数据，显著降低 I/O 开销。
- 后台任务支撑：
利用 GeminiDB Redis 的分区并行 SCAN 能力，高效执行存量数据回填、索引一致性修复及归档巡检等后台任务，确保系统在高并发下的稳定性与数据一致性。
写入流程
发送一条消息时，消息服务为会话生成递增 seq，然后依次写入消息体、会话索引和会话元信息。
- 创建新的消息体Key im:msg:{c10086}:000000000123，并写入 seq=123 这条消息的完整字段：
HSET im:msg:{c10086}:000000000123 tenantId t001 conversationId c10086 msgId m123 senderId u1001 seq 123 sendTime 1715136000123 msgType text content "hello" status normal - 将同一条消息加入会话索引分桶。后续历史消息读取时，会先从该ZSET中获取member，再根据member读取消息体：
ZADD im:idx:{c10086}:seq:000000 123 000000000123 - 更新会话最新状态，记录最新 seq、当前分桶和更新时间，便于读取最近消息时快速定位起始位置：
HSET im:conv:{c10086}:meta latestSeq 123 currentBucket 0 updateTime 1715136000123实际写入时，可以通过Pipeline减少网络往返。消息体Key、索引member和会话元信息均以 seq 为核心字段，重复执行同一条消息写入时仍能保持幂等。
读取流程
读取最近20条消息时，业务先读取会话元信息，确定最新 seq、分桶大小和当前分桶；随后从会话ZSET中按 seq 倒序读取member；最后根据member批量读取消息体。
- 读取会话元信息，确认当前最新消息序号和当前分桶：
HGETALL im:conv:{c10086}:meta假设返回 latestSeq=5123、bucketSize=5000、currentBucket=1，读取最近20条消息时，业务从第 000001 个分桶开始倒序读取。下面的命令表示：从 seq<=5123 开始，倒序取最多20个member：
ZREVRANGEBYSCORE im:idx:{c10086}:seq:000001 5123 -inf LIMIT 0 20该命令返回的是消息定位值，例如：
000000005123 000000005122 000000005121 ...
- 业务根据这些member拼接消息体Key。对于Hash消息体，通常将20个 HMGET 命令放入一个Pipeline批次中发送，减少网络往返。下面示例读取每条消息的核心字段：
# Pipeline batch HMGET im:msg:{c10086}:000000005123 senderId sendTime msgType content status HMGET im:msg:{c10086}:000000005122 senderId sendTime msgType content status HMGET im:msg:{c10086}:000000005121 senderId sendTime msgType content status ...如果消息体使用String保存序列化内容，则可以根据member拼接出20个消息体Key后使用 MGET 批量读取：
MGET im:msg:{c10086}:000000005123 im:msg:{c10086}:000000005122 ...当当前分桶返回数量不足一页时，继续读取前一个分桶。例如第 000001 个分桶只返回3条，还需要17条，则继续读取第 000000 个分桶：
ZREVRANGEBYSCORE im:idx:{c10086}:seq:000000 +inf -inf LIMIT 0 17上拉历史消息时，上一页返回的最小 seq 可作为下一页游标。假设上一页最小 seq 为 5123，下一页从 seq<=5122 开始读取：
ZREVRANGEBYSCORE im:idx:{c10086}:seq:000001 5122 -inf LIMIT 0 20返回结果组装完成后，将本页最小 seq 作为 nextCursor 返回给客户端，客户端下一次上拉时继续使用该游标。
后台动作
后台动作与在线写入、在线读取并列存在，主要用于数据补齐、数据修复等数据管理。这些动作由业务侧后台Worker执行，GeminiDB Redis提供所需的数据结构、命令能力和分区扫描能力。
GeminiDB Redis的分区扫描能力适合这类后台任务。业务可以为不同分区启动独立Worker，每个Worker使用 SCAN ... PARTITION 扫描指定分区并维护自己的cursor。多个分区并行扫描时，可以显著提升大规模Key遍历效率。
- 查看实例的数据分区信息，后台任务可以据此规划Worker数量和分区分配：
INFO ROUTE
- 扫描指定分区中的历史消息Key。PARTITION 0 表示只扫描第0个数据分区：
SCAN 0 MATCH im:msg:* COUNT 1000 PARTITION 0
存量回填
存量回填主要发生在迁移或数据模型升级时。已有历史消息中如果缺少会话索引，可以由后台Worker扫描历史消息Key，解析消息中的 conversationId、seq、sendTime 等字段，再补写消息体和会话索引。
索引修复
索引修复用于处理消息体和会话索引不一致的情况。例如消息体存在但索引缺失，或者索引中存在member但对应消息体已经被清理。该动作可以低频执行，也可以在发现异常会话后定向执行。
存量回填主要服务于迁移或模型升级阶段；索引修复属于后台治理能力，可按业务需要定期执行、低频执行或定向执行。在线历史消息查询稳定使用“消息体 + 会话索引”模型后，SCAN主要用于后台任务。
总结
本实践介绍了由传统SCAN MATCH前缀扫描到会话索引查询的IM历史消息优化实践。方案采用“消息体 + 会话ZSET索引”的数据模型：消息体保存完整消息内容，会话ZSET以seq作为排序字段、以消息定位值作为成员，历史消息接口通过conversationId + seq/cursor读取索引，再批量获取对应消息体，使查询范围收敛到单会话、单分桶索引。
GeminiDB Redis为该方案提供了更适合IM海量消息场景的基础能力。
- 其Redis兼容能力可以承接现有业务的数据结构和命令使用习惯，便于业务平滑改造；
- 其分布式架构适合承载大规模消息数据和高并发读写访问；
- 其超大容量存储、冷热数据管理和成本优化能力，有助于支撑IM历史消息长期保存和冷热分层；
- 其分区扫描能力可以将后台扫描任务拆分到多个数据分区并行处理，提升存量回填、索引修复、归档巡检等任务的执行效率。
整体来看，GeminiDB Redis在该方案中既承担在线消息数据的高性能存储角色，也承担后台数据治理的高效处理底座。在线链路通过会话索引提升查询效率，后台链路通过分区SCAN提升处理效率，两者配合后，可以将IM聊天记录查询从受全局Key扫描影响的秒级抖动，优化为更稳定的毫秒级访问体验，同时兼顾海量存储、冷热分层和长期成本控制。
