社交社区网站

🏦 场景与客户

某兴趣社区，注册用户十万量级，日活万级，靠会员与周边变现。原做法是早期用论坛程序搭的，能跑但撑不住：关注关系、帖子、评论都在几张宽表里，每次打开首页都要现算。

卡点有三个：发帖后信息流要转好几秒；查「谁关注了我」慢到没人用；审核全靠人工翻帖子。客户要的是信息流打开快、关系链能算得动、审核先过机器再过人。

📅 实施节奏

• 第 1–2 周：关系模型与信息流方案定型
• 第 3–5 周：帖子、评论、关注、通知四块核心
• 第 6–7 周：信息流与消息推送
• 第 8 周：审核后台与风控策略
• 第 9 周：压测与灰度放量

🗝️ 方案要点

• 关注关系拆两张表：关注与粉丝双向冗余，用写入成本换查询速度
• 信息流推拉结合：普通用户发帖写入粉丝收件箱，超过阈值的账号改走拉取合并
• 计数不实时统计：点赞、评论、粉丝数走增量计数，另设定时校准任务兜底
• 通知分级：站内通知必达，外部推送按免打扰规则合并发送
• 审核前置：内容先过机审规则，命中才进人工队列

⚖️ 选型与权衡

🚧 实施难点与排查

• 信息流慢：早期每次读都关联关注表。改推模式后读变快，写入变重，两边要一起看
• 大账号发帖打爆写入：百万级粉丝的账号一发帖就要写百万条。超过阈值后改走拉模式
• 计数越漂越远：缓存丢一次就少一截。加了每日校准任务后稳定
• 重复推送：重试没有幂等键，用户收到两条相同通知。补了去重键后解决

💵 成本与收益

• 成本结构：一次性开发约 1 人 × 8 周量级；缓存与队列是主要运行成本
• 收益侧：信息流打开速度明显改善，跳出率随之下降
• 人力侧：审核从全量人工转为只处理机审命中项，同样的人力能覆盖更多内容量

🛡️ 风险与保障

• 内容安全：机审规则可配置，可疑内容先隐藏再复核
• 隐私：用户可关闭被搜索、限制陌生人私信、隐藏关注列表
• 反滥用：注册、发帖、私信三处限流，异常行为触发验证
• 数据：注销账号走匿名化处理而非物理删除，历史统计口径不断档

♾️ 可复用与演进

• 「关注—信息流—通知」这套链路可平移到企业内部动态与协作社区
• 演进方向：加圈子与话题，把全局信息流拆成若干子流
• 再进一步：把互动数据回流，用于内容推荐与创作者激励