如何设计MongoDB社交关注流_拉取模式与推送模式对比

拉取模式适合中小型应用冷启动快、写入压力小但读放大明显推送模式读快实时好但写放大严重、取关清理难混合模式按关注数或请求量动态分流。拉取模式用户访问时才查关注列表和最新动态适合中小型社交应用冷启动快、写入压力小但读放大明显尤其热门用户被大量访问时容易拖慢响应。典型做法是follows 集合存 user_id → followed_id 映射查首页时先用 find({user_id: u123}) 拿出所有关注者 ID再用 $in 去 posts 集合捞最近 50 条最后按时间排序。必须给 posts.created_at 加倒序索引否则 $in sort 会全表扫$in 数组长度别超 500否则查询计划退化建议分批查比如每次 20 个 ID关注数上万的用户$in 查询可能触发内存限制MongoDB 默认 maxTimeMS 不够用得显式调大无法天然支持“已读标记”或“未读计数”需要额外字段或双写逻辑推送模式发帖时就写进每个粉丝的 feed 集合读快、实时性好但写放大严重发一条帖可能要插入上千次且关注关系变更取关需反向清理历史 feed容易漏删或卡顿。核心结构是 user_feeds 集合每条记录含 user_id接收者、post_id、created_at查首页直接 find({user_id: u123}).sort({created_at: -1})。 RedClaw 百度推出的手机端万能AI Agent助手