面向产品与研发的会话归档方案设计能力。将删除改为归档，隐藏会…

# IM“删除会话”改归档方案设计文档

一、方案目标

• 用户感知“删除”保留，底层改为归档：数据不物理删除，标记状态 + 隐藏展示
• 支持后续恢复、搜索归档会话、合规审计

二、数据模型设计

2.1 全局会话注册表

• 存储选型：注册表为高频读写小表（5000万行、每行仅元数据），建议用分布式 KV（如 Redis 集群存热数据 + MySQL 分库分表持久化），按 user_id 哈希分片
• 核心字段：
• conversation_id（全局唯一）、owner_uid、peer_uid
• status：ACTIVE / ARCHIVED / PINNED（删除即置为 ARCHIVED）
• archived_at、archive_source（用户操作/系统策略）
• version（乐观锁版本号）、last_msg_seq（用于UI排序）
• 索引：(owner_uid, status, last_msg_seq) 支撑会话列表查询；归档查询走 (owner_uid, status, archived_at)

2.2 消息数据

• 5000万条消息不动存储结构，仅通过注册表状态控制可见性；冷归档数据可异步迁移至对象存储/列存（成本敏感时二期做）

三、RPC 快照接口设计

3.1 快照协议

• 提供 GetConversationSnapshot(uid, cursor, limit, status_filter)：服务端按注册表过滤 status=ACTIVE 后返回快照
• 快照结构：{snapshot_version, conversations[], next_cursor}，snapshot_version 取注册表全局版本（或按用户维度的递增 seq）
• 增量同步：客户端携带本地 snapshot_version，服务端 diff 后返回变更列表（增/改/删标记），降低带宽

3.2 归档操作 RPC

• ArchiveConversation(uid, conversation_id, expect_version)：CAS 更新状态，失败返回冲突让客户端刷新
• 幂等设计：重复归档同一会话直接返回成功
• 双写保护：归档期间新消息照常落库，仅 UI 不展示

四、UI 过滤层设计

• 客户端过滤：会话列表渲染时过滤 status != ACTIVE，与服务端过滤双保险（防止旧版本客户端/缓存脏数据）
• 交互保留：长按/右键“删除”→ 调 Archive RPC → 本地立即移除（乐观更新）→ 失败回滚并提示
• 归档入口：设置页提供“归档会话”列表，支持搜索、恢复（status 置回 ACTIVE）
• 未读处理：归档会话不参与未读数角标计算，需在未读聚合逻辑中排除

五、灰度与兼容

• 灰度策略：按 uid 尾号 1% → 10% → 100%，观察归档 RPC 错误率、客户端崩溃率
• 旧版兼容：服务端对旧版本客户端仍返回过滤后快照，旧客户端无感知
• 回滚方案：功能开关控制，状态字段语义向后兼容，可一键切回物理删除路径

六、监控指标

• 归档 RPC 成功率、P99 延迟、注册表分片负载、快照增量同步命中率、归档会话恢复率