推荐流_feed 流_吃饭流_极简版 1.0 想了好几天了准备代码完善一下

[echofather]

先决条件

• 前期内容少客户少
• 非新闻类时间不是特别紧要
• 内容数量最好能达到 1000+
• 用户数量少不到 10w，无需为每个用户个性化定制
• 垂直领域，用户群体聚合

设计思路

• 吃和喂的操作大部分交给前端，减少服务器压力
• 类似定时更新的排行榜，热度榜，百度热榜，云音乐
• 排名菜的热度，友圈。
• 前端吃的时候不能光吃热的，要冷热一块吃，但是热的占比要大
• 系统里有角色，厨师 cook，客户 eat，饭馆 feed，饭菜 moments，饭菜热度 hot

厨师 cook

• customer 表 cook 值不同，影响 moment 的 hot 值，大 V，2，10

饭菜 moment

• 冷启动，根据 eat 量，浏览量，点赞，评论，发布人，时间计算热度
• 饭菜热度 hot 是计算出来的，每一个菜都会有 hot 值
• hot 热度不是一直不变的，会随时间变凉。

饭馆 feed

• 根据 hot 给 moment 排序形成总表，redis，id+hot
• 服务端生成的 feed 是所有的菜,客户请求的 feed 表不是无限，最好限制在 500 左右，取 300 个头部，150 个中部，50 个尾部非 0 非负：6：3：1
• 等待客户请求
• 小餐馆没有必要给每位客人定制 feed 表，大家就公用一个 feed 表就 ok

客户 eat

• 客户需要根据自己的需要进行请求接收新的 feed
• 新鲜的 feed 表需要第一时间根据 eat 表去重，eat 时候不允许重复，使用布隆过滤
• eat 的时候可以随机，头部占比大一点，其他占比小一点：6：3：1 。10id-》详细列表。
• 1 。eat 请求的时候服务端要对吃掉的菜 10id 做降温处理，2 。eat 量累加，eat 量快要=60%app 客户量的时候进行急速降温处理。
• feed 表被曝光会放到 eat 表，前端
• eat 表不能无限大，限制值，超出就开始拉

客户 feedback

• 对于感兴趣的 moment 客户会进行反馈（查看详情），点赞，评论，长时间浏览，完播率，等这一系列的操作变成客户的反馈事件
• 有尊贵的客户也有找事的，他们的 feedback 值不同，对 hot 值的反馈影响有差异
• feedback 会被反馈到饭馆的 moment 的 hot 值
• 从而影响 feed 表排序，形成闭环

代码改造

• 创建 sysrecommend 表
• 推荐 recmond 模块
• capi 查询友圈加个接口：根据 10ids 查询返回
• capi 加 feed 接口，从 redis 获取一定数量的 500ids
• sapi 加接口 makefeed 全量同步：遍历计算 moments 的 hot 值，保存到 redis
• redis 存储结构，id：hot，以 sorted set 格式存
• 新增的友圈直接+权重算到到 redis 里
• sapi 加接口，根据 ids 返回 redis 里的 hot 值。
• sapi 加接口，可以直接手动调整 redis，hot 值
• capi 加接口，可以调节 redishot 值大小，如果没有那么就新增
• 加 cook 权重，feedback 权重，
• 初始值为 2 。
• 后台创建的用户权重值为 5 。
• hot 值
• capi 加 feed 操作，增改查
• sapi 加 feed 操作，增改查
• 还需要根据类目来做 feed
• 计算规则可配置

下一步做个性推荐：

• 获取用户操作列表，查看表，评论表，点赞表，收藏表，用户标签权重计算结果,找同标签内容，找同质用户
• 流计算，获得新的个人 feed 列表，每次刷新个人 feed 都会更新