tkmind_go/documentation/docs/guides/plaza/05-feed-algorithm.md

---
sidebar_position: 6
title: Feed 算法
sidebar_label: Feed 算法
description: 广场热度排序公式、算法演化路径、Redis 计数策略和推荐迁移时机
---

# Feed 算法

## 设计原则

- **初期不做个性化推荐**：冷启动时用户行为数据不足，协同过滤效果差于热度排序。
- **热度排序足够用到 10 万帖子**：时间衰减 + 多维互动权重，工程实现简单，效果可预期。
- **透明可调**：热度公式的权重系数写在配置表里，运营可以实时调整，不需要发版。
- **推荐算法是独立演化的模块**：等数据量够了再接入，接口协议从第一天就预留好。

---

## 热度排序公式（初期）

```
hot_score = (V × w_v + L × w_l + C × w_c + S × w_s) / (T + decay_base) ^ decay_exp
```

| 变量 | 含义 | 默认权重 |
| --- | --- | --- |
| V | view_count 浏览量 | w_v = 0.1 |
| L | like_count 点赞数 | w_l = 3.0 |
| C | comment_count 评论数 | w_c = 5.0 |
| S | collect_count 收藏数 | w_s = 4.0 |
| T | 帖子年龄（小时），`NOW() - published_at` | - |
| decay_base | 时间衰减基数 | 默认 2 |
| decay_exp | 时间衰减指数 | 默认 1.5 |

**示例**：

一篇帖子发布 3 小时后，获得 500 次浏览、20 个点赞、3 条评论、5 个收藏：

```
分子 = 500×0.1 + 20×3 + 3×5 + 5×4 = 50 + 60 + 15 + 20 = 145
分母 = (3 + 2)^1.5 = 5^1.5 ≈ 11.18
hot_score ≈ 12.97
```

同样互动量、发布 24 小时后：

```
分母 = (24 + 2)^1.5 = 26^1.5 ≈ 132.6
hot_score ≈ 1.09
```

时间衰减效果明显，保证新内容有机会上热门。

---

## 权重配置表

```sql
CREATE TABLE plaza_algorithm_config (
    key         VARCHAR(100) NOT NULL,
    value       DOUBLE       NOT NULL,
    description VARCHAR(200) NOT NULL DEFAULT '',
    updated_at  DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (key)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

INSERT INTO plaza_algorithm_config VALUES
  ('w_view',      0.1,  '浏览量权重',   NOW()),
  ('w_like',      3.0,  '点赞权重',     NOW()),
  ('w_comment',   5.0,  '评论权重',     NOW()),
  ('w_collect',   4.0,  '收藏权重',     NOW()),
  ('decay_base',  2.0,  '时间衰减基数', NOW()),
  ('decay_exp',   1.5,  '时间衰减指数', NOW());
```

后台定时任务读取配置表后计算，运营修改配置后下次计算周期生效。

---

## 计算时机

```text
触发条件                          执行动作
──────────────────────────────    ──────────────────────────────
每 10 分钟定时任务                重新计算过去 48 小时内发布帖子的 hot_score
新帖发布到广场                    立即计算初始 hot_score（基于 0 互动 + 年龄 0）
帖子互动量发生变化                不立即重算，等下一次定时任务
```

**为什么不实时重算**：每次点赞都重算 hot_score 并回写 MySQL，在高并发下会造成锁竞争。Redis 实时累计计数，定时批量回写 + 重算是更稳定的方案。

---

## Redis 计数策略

```text
# 每次浏览
INCR plaza:post:{id}:view_count

# 点赞
INCR plaza:post:{id}:like_count

# 取消点赞
DECR plaza:post:{id}:like_count

# 防止负数
if GET plaza:post:{id}:like_count < 0:
    SET plaza:post:{id}:like_count 0
```

**定时同步任务（每 5 分钟）**：

```text
1. 维护 Redis SET plaza:sync:post_ids（每次 INCR 时将 post_id SADD 入集合）
2. SMEMBERS plaza:sync:post_ids，批量 GET 计数
3. 批量 UPDATE plaza_posts … WHERE id IN (...)
4. SREM 已同步的 post_id
```

> 避免对 `plaza:post:*` 做全量 SCAN；帖子量大时 SCAN 会阻塞 Redis。Sprint 3 前帖子少时可临时 SCAN，上线前必须改为 SET 增量同步。

**Redis 数据持久化**：开启 AOF，每秒 fsync，允许最多 1 秒的计数损失。

---

## Feed 缓存策略

```text
广场首页热门 Feed（全部分类）：
  缓存 Key:  plaza:feed:hot:all:page:1
  TTL:       5 分钟
  生成时机:  定时任务重算 hot_score 后刷新

分类热门 Feed：
  缓存 Key:  plaza:feed:hot:{category_slug}:page:1
  TTL:       5 分钟

最新 Feed：
  缓存 Key:  plaza:feed:new:all:cursor:{cursor}
  TTL:       60 秒（最新列表变化快）

精选位（Sprint 5）：
  缓存 Key:  plaza:featured:{position}
  TTL:       5 分钟
  合并规则:  见 04-backend-api「精选与 Feed 合并规则」

新帖 status 变为 published 后：
  DEL plaza:feed:hot:* plaza:feed:new:*（下次请求重建）
```

---

## Feed 接口降级策略

| 场景 | 降级行为 |
| --- | --- |
| Redis 不可用 | 直接查 MySQL `ORDER BY hot_score DESC`，性能下降但不中断 |
| 热度未计算（新帖） | 按 `published_at DESC` 兜底 |
| 分类无帖子 | 返回全局热门帖子，前端提示"该分类暂无内容" |

---

## 算法演化路径

### 第一阶段：热度排序（现在）

纯公式，无需用户行为数据，工程简单。

### 第二阶段：兴趣标签匹配（月活 1 万后）

- 从用户的浏览历史和点赞行为中推断兴趣标签（与帖子的 `tags` 字段匹配）。
- 在热度排序基础上，对匹配用户兴趣的帖子 hot_score 乘以权重系数（1.2–1.5）。
- 不需要机器学习模型，纯 SQL 可实现。

### 第三阶段：协同过滤（月活 10 万后）

- 引入独立 Python 推荐服务。
- 基于用户行为矩阵（浏览、点赞、收藏）进行 item-based 协同过滤。
- 后端 `/api/plaza/v1/feed` 接口保持不变，内部调用推荐服务获取帖子 ID 列表。
- **接口协议从现在就预留**：响应中的 `posts` 数组顺序即为推荐顺序，客户端无需感知算法类型。

### 第四阶段：实时流推荐（月活 100 万后）

- Flink/Spark Streaming 实时处理行为流。
- 向量召回 + 精排模型。
- A/B 测试框架。

---

## 防刷策略

初期使用简单规则，不上机器学习：

- 同一 IP 对同一帖子，24 小时内只计 1 次有效浏览。
  - 实现：Redis `SET plaza:view:{ip_hash}:{post_id} 1 EX 86400 NX`，SET 成功才 INCR 计数。
- 同一用户重复点赞（已有 UNIQUE 约束）：数据库层保证幂等。
- 短时间内大量来自同一 IP 的点赞：限流中间件 + 运营人工核查。
- 评论刷量：同一用户对同一帖子每小时最多发 10 条评论。

---

## 新帖冷启动

新帖发布后 hot_score = 0，会排在热门列表末尾，导致新帖永远没有曝光机会。

解决方案：「最新」Tab 独立于「热门」存在，新帖默认进入「最新」Feed，以 `published_at DESC` 排序。

「最新」是新内容的曝光入口，「热门」是经过验证的内容的沉淀展示。这两个 Tab 服务不同的用户动机。