一、收藏功能的业务价值与需求拆解

收藏是内容型产品中最基础的高频互动行为之一。相比点赞、评论等轻量互动，收藏承载着更强的“留存意图”，用户把内容收入囊中，意味着未来还会回来再次消费。对产品而言，收藏率是衡量内容长期价值的重要信号；对用户而言，收藏夹则是个人知识管理与内容回顾的入口。

一个完整的收藏功能，通常需要支撑以下核心场景：

1. 收藏与取消收藏：用户对图文、视频、评论等不同类型的对象执行收藏或取消操作；
2. 收藏状态查询：内容详情页需要实时展示“当前用户是否已收藏”以及总收藏数；
3. 收藏列表：个人中心按时间倒序分页展示收藏内容，并支持在列表内直接取消收藏；
4. 收藏分组（可选进阶）：允许用户将内容归入不同收藏夹，便于整理。

需求看似简单，但在亿级用户、高并发访问的场景下，会依次暴露出幂等、去重、计数一致性、热点读写等典型工程问题。下文按照“数据模型 → 接口设计 → 一致性 → 性能优化 → 可观测性”的顺序逐层展开。

二、数据模型设计：一张关系表打基础

收藏的本质是“用户与对象之间的多对多关系”，核心是一张收藏关系表：

CREATE TABLE user_favorite (
  id          BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  user_id     BIGINT UNSIGNED NOT NULL COMMENT '用户ID',
  target_type TINYINT  UNSIGNED NOT NULL COMMENT '对象类型：1图文 2视频 3评论',
  target_id   BIGINT UNSIGNED NOT NULL COMMENT '对象ID',
  status      TINYINT  UNSIGNED NOT NULL DEFAULT 1 COMMENT '1有效 0已取消',
  created_at  DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  updated_at  DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  UNIQUE KEY uk_user_target (user_id, target_type, target_id),
  KEY idx_user_time (user_id, status, created_at)
);

几个关键设计决策值得展开说明：

1. 唯一索引防重：(user_id, target_type, target_id) 唯一索引从数据库层面杜绝重复收藏，是整条链路幂等性的最后防线。任何应用层的判重逻辑都可能因并发而失效，数据库约束才是可靠的兜底。
2. 软删除优于硬删除：取消收藏时将 status 置 0 而非物理删除行。这样“收藏—取消—再收藏”的循环操作不会触发唯一键冲突，也完整保留了行为数据，可供风控、推荐等下游系统分析使用。
3. 收藏夹独立建模：若支持分组，应将“收藏夹表”与“收藏关系表”分开，关系表仅增加 folder_id 字段做关联，避免把分组信息耦合进核心读写链路，导致表结构频繁变更。
4. 水平拆分预案：数据量达到十亿级时，按 user_id 哈希分表。由于绝大多数查询都携带 user_id（查列表、查状态），按用户维度分片可以让请求稳定路由到单一分片，避免昂贵的跨片聚合。

三、接口设计与幂等性保障

对外暴露的核心接口通常有四个：收藏、取消收藏、收藏状态批量查询、收藏列表分页查询。

收藏接口的幂等是第一要点。 网络重试、用户手抖双击都会造成重复请求，处理思路是“直接写库、靠唯一索引兜底、冲突即视为成功”：

// 收藏接口伪代码
function favorite(userId, targetType, targetId):
    # 1. upsert：记录不存在则插入，已存在则将 status 恢复为 1
    result = db.execute("
        INSERT INTO user_favorite (user_id, target_type, target_id, status)
        VALUES (?, ?, ?, 1)
        ON DUPLICATE KEY UPDATE status = 1, updated_at = NOW()
    ", userId, targetType, targetId)
    # 2. 仅当状态由"取消"真正变为"有效"时，才投递计数变更消息
    if result.statusChanged:
        mq.publish("favorite_changed", {
            userId: userId, targetType: targetType,
            targetId: targetId, action: "ADD"
        })

两点细节值得强调：

• ON DUPLICATE KEY UPDATE 将“先查询、再插入”合并为一次数据库交互，天然规避了并发场景下 check-then-act 的竞态条件；
• 只有状态真正发生变化时才投递计数消息，从源头减少重复消息；下游消费侧再配合幂等键去重，双保险确保计数不虚高。

取消收藏的处理完全对称：将 status 置 0，action 记为 REMOVE。

状态查询要支持批量。 详情页、信息流列表往往需要一次性判断几十条内容“我是否已收藏”，应提供批量查询接口，一次往返返回 target_id 到布尔值的映射，避免前端循环发起单条请求造成请求数放大。

四、计数一致性：异步更新 + 定时对账

内容的收藏总数是典型的“读多写多、允许短暂误差”的数据。如果每次收藏都同步更新内容主表的 count 字段，爆款内容会产生严重的行锁竞争，拖垮写入吞吐。

业界通行做法是三段式架构：

1. 实时层：收藏事件写入消息队列，计数服务消费后更新分布式缓存中的计数器（原子自增/自减）；
2. 落库层：计数服务按内容维度在内存中聚合增量，每隔数百毫秒到数秒批量刷回数据库，显著减少写放大；
3. 对账层：定时任务（如每小时）抽样比对“关系表聚合值”与“缓存计数”，偏差超过阈值时以关系表为准修正缓存与落库值。

-- 对账基准：以关系表聚合结果为唯一事实源
SELECT target_id, COUNT(*) AS cnt
FROM user_favorite
WHERE target_type = 1 AND status = 1
GROUP BY target_id;

这套设计的核心哲学是：关系表是唯一事实源（Source of Truth），缓存与冗余计数只是可重建的加速层，任何不一致都可以通过对账收敛。展示层对计数允许秒级误差，用户体验几乎无损，却换来了写入链路的极大简化。

五、高并发读写优化

5.1 读路径：多级缓存

• 收藏数缓存：以 fav{type}:{target_id} 为键缓存计数，热点内容详情页直接读缓存，数据库只承担回源与刷盘；
• 是否已收藏：以 fav{user_id}:{type} 为键，用集合或位图记录用户近期收藏的对象，实现 O(1) 的状态判断；
• 收藏列表缓存：使用有序集合结构，成员为 target_id、分值为收藏时间戳，天然支持按时间倒序的范围查询分页。

缓存更新采用“先更新数据库、再删除缓存”的旁路缓存模式，并设置过期时间兜底。需要特别注意：重度用户的收藏列表可能长达数万条，应只缓存最近 N 条，翻页超过缓存范围后回源数据库，并以 created_at 作为游标做深分页，避免大偏移量查询。

5.2 写路径：削峰与异步化

爆款内容发布瞬间，收藏请求可能瞬时冲高数个量级。除消息队列削峰外，还可以组合以下手段：

• 前端防抖与请求合并：快速连点只发出一次请求；
• 网关限流：按用户维度令牌桶限流，防刷防爬；
• 异步确认：写请求进入队列即返回成功，前端乐观更新 UI，后端异步落库。这要求 UI 对最终失败有补偿能力（如状态回退并轻提示），保证“感知快”与“最终对”兼得。

5.3 数据库层面

• 读写分离：列表查询走从库，写操作走主库，横向扩展读能力；
• 冷热分离：将两年以上的历史收藏归档到冷存储，在线表只保留热数据，控制单表规模与 B+ 树索引高度；
• 慢查询治理：idx_user_time 索引覆盖“按用户查有效收藏、按时间倒序”的高频路径，避免 filesort 与深分页扫描。

六、前端交互与体验细节

后端之外，体验质量很大程度取决于前端实现：

1. 乐观更新：点击收藏立即变色、数字加一，请求失败再回滚并提示，感知延迟趋近于零；
2. 状态同步：登录态切换、多端操作之后，进入详情页需重新拉取收藏状态，避免展示陈旧状态造成误操作；
3. 防重复点击：请求在途时按钮置为加载态，防止双击产生两条并发请求；
4. 成功引导：收藏成功后给予轻量反馈，可选引导用户归入收藏夹，提升整理率而不打断主流程。

七、可观测性与容错

收藏链路串联了数据库、缓存、消息队列多个组件，任何一环抖动都会影响核心体验，必须建立完整的可观测体系：

• 核心指标：收藏接口 QPS、成功率、P99 延迟、消息消费积压量、缓存命中率、计数对账偏差率；
• 告警规则：消费积压超阈值、对账偏差率突增、数据库主从延迟过大时触发分级告警；
• 降级预案：计数缓存失效时回源数据库聚合查询并施加限流保护；消息队列不可用时降级为同步写库加异步补偿任务，确保核心收藏动作始终可用。

八、总结

收藏功能是“小切口、深工程”的典型代表：一个按钮背后，串联了关系建模、幂等控制、异步计数、多级缓存、削峰限流与数据对账等一整套工程方法。落地时建议把握三条原则：其一，数据库唯一约束作为幂等的最后防线；其二，关系表作为唯一事实源，其余缓存与冗余皆为可重建的加速层；其三，用异步化与对账机制在体验与一致性之间取得平衡。掌握这套方法论，不仅可以做好收藏，也能平滑迁移到点赞、关注、浏览历史等几乎所有“用户—对象关系”类功能的设计中。