关注关系图谱与推荐关注：共同关注、传播路径与社交推荐

图模型：
□ 节点（Node）：用户
□ 有向边（Directed Edge）：关注（follower → followee）
□ 自环：不允许（不能关注自己）
□ 反边：互相关注（双向）→ 好友/双向关系，可额外标记

图的形态：
邻接（关注的人）：follower_id → followee_id（出边）
反邻接（粉丝）：followee_id ← follower_id（入边）

规模直觉：
千万用户 → 亿级边 → 单用户度数（关注数/粉丝数）分布极度倾斜

两种「图视角」：
□ 行视角：我关注了谁（出边），决定我的时间线内容源
□ 列视角：谁关注了我（入边），决定我的粉丝与影响力

物理存储（关系表）：
follow(follower_id, followee_id, created_at)
  + 唯一索引 (follower_id, followee_id)   → 关注视角（邻接）
  + 二级索引 (followee_id, follower_id)   → 粉丝视角（反邻接）

缓存层：
□ 我的关注列表：follow:{uid} （Redis set/zset）
□ 我的粉丝列表：fan:{uid}（大 V 粉丝缓存在 Redis/专用存储）
□ 是否已关注：is_follow:{follower}:{followee}（布隆/缓存）

大 V 特殊性：
□ 大 V 粉丝数千万 → 粉丝列表不能全量入缓存
□ 只缓存「Top 粉丝」或分页读取，全量用专用存储

查询模式：
□ 「我关注了没」→ 唯一索引点查，O(1)
□ 「我的关注列表」→ 索引扫描，分页
□ 「谁关注了我」→ 反邻接扫描（大 V 走专用通道）

共同关注 = 我关注的 ∩ 对方关注的
共同粉丝 = 我的粉丝 ∩ 对方的粉丝

实现（小集合求交）：
□ 取两人关注 id 集合 → 求交集
□ 小集合直接内存求交（各取 Top 5000，交集即可用）
□ 大集合用布隆过滤器先过滤，再精确求交

热度排序：
□ 共同关注不只看「存在」，还要排「谁值得推荐」
□ 排序信号：共同关注者的粉丝数、活跃度、与你关注的时间

应用场景：
□ 「TA 也关注了」推荐（发现新内容源）
□ 「你们有 N 个共同关注」社交粘性提示
□ 关系判定：共同关注多 → 兴趣相似 → 值得推荐

二度关系定义：
□ 我关注了 A，A 关注了 B（B ≠ 我，且我没关注 B）→ B 是我的二度候选

扩展路径：
□ 直接二度：我的关注 → 他们的关注（一跳扩展）
□ 热门二度：二度关系里被关注最多的 → 「大家都在关注」
□ 逆二度：粉丝的粉丝（潜在传播对象，营销场景）

计算约束：
□ 二度扩展是「扇出爆炸」重灾区：
  我关注 100 人 × 每人关注 300 人 = 3 万候选 → 必须限量/加权
□ 只算「Top-K」：每个一度节点只贡献前 K 个二度候选

二度推荐示例：
候选 = 我的关注集合的关注（去重、去掉已关注/自己）
权重 = 共同关注数 / 被关注热度 / 新鲜度
→ 取 Top-N 作为「推荐关注」

1. 协同过滤（基于关系的协同）：
   我和用户 U 的共同关注越多 → U 值得关注
   → 直接基于共同关注计数，简单有效

2. 基于相似（用户兴趣相似）：
   画像相似的用户关注的东西 → 推荐给我
   → 用兴趣向量/内容偏好算相似度（见个性化篇）

3. 基于传播/热门：
   「大家都在关注」的上升中作者
   → 全局热度 + 新鲜度，适合冷启动

组合策略：
  候选池 = 协同(60%) + 相似(25%) + 热门(15%)
  排序 = 权重 * (信号强度) + 新鲜度 + 多样性

冷启动与探索：
□ 新用户：热门作者为主，引导关注
□ 老用户：协同为主，保持「发现感」
□ 探索配额：给长尾优质作者曝光机会

传播数据结构：
□ 转发链：root_post_id → repost_id → repost_id → ...
□ 每层记录「谁转发的」「谁看到的」
□ 原始内容 + 转发树（有向树结构）

传播分析：
□ 传播深度/广度：多少层、多少节点触达
□ 关键传播者：把内容推向下一个社区的「桥梁」
□ 感染路径：从哪个粉丝群扩散出去的
□ 影响力分：粉丝数 × 活跃度 × 历史传播效率

工程用途：
□ 发现爆款内容的传播模式（哪类内容更容易扩散）
□ 反垃圾：识别「刷转发」的机器传播路径
□ 推荐：借传播路径做「你关注的人转发了」的社交推荐

关系表（PostgreSQL/MySQL）：
□ 适合：单点查询、交集查询、分页（我们大部分场景）
□ 优点：生态成熟、事务、与业务表同库
□ 局限：多跳图查询（2-3 跳以上）SQL 复杂且慢

图数据库（Neo4j/ArangoDB/TigerGraph）：
□ 适合：深度图查询、路径分析、图算法（社区发现/中心度）
□ 优点：多跳遍历快、图算法原生
□ 局限：运维成本、与业务系统分离

混合方案（主流）：
□ 日常功能（关注/粉丝/共同关注）走关系表
□ 深度分析（传播路径/社区发现/影响力）定期导到图库批处理

选型判断：
□ 只要「点查 + 1 跳」→ 关系表足够
□ 需要「3+ 跳 / 图算法」且量大 → 图库或图批处理
□ 绝大多数社交产品的「推荐关注/共同关注」只需 1-2 跳 → 关系表够

阶段 1（万级用户）：单 follow 表 + 索引
  → 全功能可用

阶段 2（百万级）：缓存化
  → 关注/粉丝列表入 Redis，大 V 特殊处理
  → 共同关注缓存 + 布隆过滤

阶段 3（千万级）：图服务化
  → 独立关系服务（Graph Service）
  → 读写分离、粉丝/关注分库（按用户 id 分片）
  → 布隆 + Top-K 缓存成标配

阶段 4（亿级）：专用图存储 + 批处理分析
  → 图查询走专用引擎（自研/图库）
  → 传播/推荐算法离线批处理

演进信号：
□ 关注列表查询 P99 超过预算 → 缓存化
□ 共同关注/推荐关注计算超时 → 预计算 + 缓存
□ 关系服务与业务耦合 → 拆独立服务

关注风控场景：
□ 批量刷粉（僵尸号互相关注/关注真人）
□ 关注后再取关（洗关注，涨粉骗局）
□ 恶意关注（骚扰、引战）

风控信号：
□ 关注频率异常（秒级关注数百人）
□ 关注/取关比例异常（关注后快速取关）
□ 关注对象的集中度（全关注同一批人）
□ 新号权重：注册时间短 → 关注可信度低

治理手段：
□ 限流：关注操作按用户维度限频（见限流篇）
□ 异步风控：批量关注行为进风控队列，命中即限/封
□ 惩罚：降权（其关注不计入对方粉丝数）、警告、封禁

实现示例：
关注请求 → 风控检查（频率/新号/集中度）→ 放行 or 限流
批量取关 → 触发洗关注检测 → 计入风控分