动态内容收藏功能的设计与实现

在内容平台中，“收藏”是一个看似简单、实则牵涉面广的基础能力。用户点击收藏按钮的那一刻，背后涉及数据建模、状态同步、计数一致性、查询性能等一系列工程问题。本文以“动态内容的收藏”为切入点，系统梳理该功能从设计到落地的完整思路，并给出可复用的工程实践建议。

一、功能定位与核心需求拆解

收藏功能的本质是建立“用户—内容”之间的持久化关联关系。围绕这一关系，可以拆解出四类核心需求：

1. 写入需求：用户对某条动态执行收藏或取消收藏，操作需即时生效且可重复执行而不产生副作用。
2. 状态查询需求：在信息流、详情页等场景中，需要快速判断“当前用户是否已收藏该内容”，以正确渲染按钮状态。
3. 列表查询需求：用户需要按时间倒序分页浏览自己的收藏列表，并可能按内容类型、收藏时间等维度筛选。
4. 计数需求：内容维度需要展示被收藏总数，用于体现内容热度。

这四类需求对应截然不同的访问模式：写入是高频小事务，状态查询是点查，列表查询是范围扫描，计数则是聚合统计。若试图用一套存储同时满足所有需求，往往会在某一维度上做出妥协。因此，合理的做法是先明确各需求的优先级与量级，再进行分层设计。

二、数据建模：关系表还是宽表

最直观的建模方式是一张关系表：

CREATE TABLE user_favorite (
  user_id      BIGINT NOT NULL,
  content_id   BIGINT NOT NULL,
  content_type TINYINT NOT NULL,
  created_at   DATETIME NOT NULL,
  status       TINYINT NOT NULL DEFAULT 1,
  PRIMARY KEY (user_id, content_id, content_type),
  KEY idx_user_time (user_id, created_at)
);

该设计的要点如下：

• 以用户维度作为主键前缀：因为“我的收藏列表”是最主要的查询入口，按用户聚簇可以让列表查询走主键顺序扫描，避免额外排序。
• 联合唯一约束保证幂等：同一用户对同一内容重复收藏时，通过主键冲突转为更新操作，天然实现幂等。
• 软删除而非物理删除：使用 status 字段标记取消收藏，保留历史行为数据，便于后续做行为分析与风控。若数据量压力大，可再配合定期归档策略。

需要权衡的是：如果业务对“内容被哪些用户收藏”也有查询诉求（例如做收藏用户画像），上述以用户为前缀的主键就不够友好，需要额外建立反向索引表。是否值得，取决于该查询的频次与实时性要求。多数场景下，这类反向查询可以走离线数仓而非在线库。

三、状态一致性与计数问题

收藏功能最容易出问题的地方是计数。

3.1 计数为什么不能实时 count

在列表页展示“XX 人收藏”时，若每次渲染都执行 SELECT COUNT(*)，在数据量上升后必然不可接受。常见做法是维护一个独立的计数记录，写入时增量更新：

UPDATE content_counter
SET favorite_count = favorite_count + 1
WHERE content_id = ?;

但增量更新引入了新的问题：收藏表与计数表可能不一致。例如收藏记录写入成功、计数更新失败，或取消收藏重复执行导致计数被多次扣减。

3.2 保证一致性的三种策略

策略一：同事务更新。 将收藏记录与计数更新放在同一数据库事务中，依靠事务原子性保证一致。实现简单，但会增加写事务的持锁时间，在热点内容上容易产生行锁竞争。

策略二：幂等 + 变更判定。 关键在于区分“本次操作是否真正改变了收藏状态”。只有当状态从“未收藏”变为“已收藏”时才加一，从“已收藏”变为“未收藏”时才减一。可通过影响行数判断：

-- 收藏：仅当原状态为未收藏时生效
UPDATE user_favorite
SET status = 1, created_at = NOW()
WHERE user_id = ? AND content_id = ? AND content_type = ? AND status = 0;
-- 若 affected_rows = 1，才对计数 +1

这一方式把“是否变更”的判断下沉到存储层，避免了先查后写的并发窗口。

策略三：异步校准。 在线路径只做增量更新，同时记录变更日志，由后台任务定期对账，以收藏明细表为准修正计数。这是大规模系统的常见兜底手段，能够容忍短时不一致，但必须保证最终收敛。

实践中，策略二通常是必选项，策略三作为兜底，策略一在低并发场景下可作为简化方案。

3.3 热点内容的写竞争

对于爆款动态，短时间内的收藏写入会集中打在同一行计数记录上，形成行锁瓶颈。可选的处理方式包括：

• 将计数拆分为多个分片（如按 hash 取模写入 N 条记录），读取时求和；
• 在线只写变更日志，计数由近实时的聚合任务产出，读取走缓存；
• 对计数展示做降级，允许短时延迟。

具体选择需结合业务对计数实时性的敏感程度。若计数仅用于展示热度、允许秒级延迟，异步聚合几乎总是更优解。

四、查询性能优化

4.1 状态查询的缓存策略

信息流场景中，一屏可能包含数十条动态，若逐条查询收藏状态会产生大量点查。可行的优化方向：

• 批量查询：一次请求携带多个内容 ID，用 IN 查询一次性取回当前用户的收藏集合，再在内存中做映射。这能将 N 次点查降为 1 次范围查询。
• 本地缓存：对单用户短期内反复访问的信息流，可在接入层缓存其收藏集合的摘要，设置较短过期时间。
• 位图结构：当内容 ID 空间可控时，可用位图表示某用户的收藏集合，判断与批量读取都极为高效，但需注意稀疏场景下的内存开销。

4.2 收藏列表的分页

分页应避免深翻页带来的性能衰减。推荐使用游标分页，以 (created_at, content_id) 作为游标：

SELECT content_id, created_at
FROM user_favorite
WHERE user_id = ? AND status = 1
  AND (created_at < ? OR (created_at = ? AND content_id < ?))
ORDER BY created_at DESC, content_id DESC
LIMIT ?;

相比 OFFSET，游标分页的代价与页码无关，且不会因新数据插入导致翻页错乱。需要注意的是，收藏列表通常还要回表取内容详情，建议先取 ID 列表再批量拉取内容，避免大表关联。

4.3 列表与详情的读写分离

收藏列表属于典型的读多写少场景，可将列表查询路由到只读副本。但必须考虑主从延迟带来的“收藏后立刻查看列表却看不到”的问题。缓解手段包括：写后短时间内强制走主库，或在前端做乐观插入，将新收藏项先行渲染。

五、接口设计要点

一个清晰的接口契约能显著降低联调与后续维护成本。建议至少提供：

• POST /favorites：收藏，请求体含内容标识；返回当前状态与最新计数。
• DELETE /favorites：取消收藏，语义同上。
• GET /favorites/status?ids=...：批量查询收藏状态。
• GET /favorites：分页查询收藏列表，支持游标参数。

设计时有几个细节值得注意：

1. 收藏与取消收藏都应返回操作后的最终状态，而非仅返回成功与否。这样客户端无需二次查询即可更新 UI，也便于处理并发下的状态覆盖。
2. 批量状态查询需限制单次 ID 数量，防止超长请求拖垮存储。
3. 接口应保持幂等语义，重复调用不产生额外副作用，这对弱网重试场景尤为重要。

六、边界情况与工程细节

• 内容被删除或下架：收藏关系中仍保留记录，但列表渲染时需过滤或占位提示，避免出现空白项。建议在内容侧提供批量可用性查询。
• 账号注销：需清理或匿名化该用户的收藏数据，注意与计数修正解耦，避免大批量删除时冲击计数表。
• 权限与可见性：私密内容的收藏列表不应对外暴露，列表接口需做可见性过滤。
• 重复收藏的时间更新：用户取消后再次收藏，created_at 应更新为最新时间，以保证列表按最近收藏排序符合直觉。

七、小结

动态收藏功能的难点不在单个接口的实现，而在于写入幂等、计数一致、查询高效三者之间的平衡。工程上的稳妥路径是：以用户维度建模保证列表查询效率，用状态变更判定加同事务更新保证计数基本准确，以异步对账作为最终兜底，再通过批量查询与游标分页控制读路径成本。把这些基础问题处理清楚，收藏能力才能在上量之后依然稳定可控。