WorkMigration/智能鞋/5、社区.md

数据

相关表

• forum （论坛分区）
• subject （帖子）
• subject_hot （热门帖子）
• subject_media （帖子附件上传）
• subject_share_count （帖子分享统计）
• subject_tag （帖子标签）
• subject_user_collection （收集发帖的用户ID，方便统计）
• subject_view_count （帖子访问数）
• forum_date_view_record （论坛按日访问次数）
• forum_top （论坛置顶帖）
• forum_user_collection （收集论坛访问用户ID，方便统计）
• forum_date_view_record （论坛按日访问流水）
• game_subject （游戏介绍页评论区的专属帖子）
• comment （评论）
• comment_share_count （评论分享数）
• comment_user_collection （收集发表评论用户ID，方便统计）
• like_record （点赞）
• likerecord_user_collection（收集点赞用户ID，方便统计）
• message （私信）
• notice （通知）
• user_block （用户自己的屏蔽数据）
• userfollow* （用户关注, 粉丝/订阅者）
• user_followgroup* （用户关注分组，实际没用到）
• user_friend （好友，即相互关注）
• user_report （用户举报）
• user_subject_top （用户个人主页置顶的帖子）

---

相关的队列消费

以前由于时间关系，采用了非常简易的分批队列，基于redis。

基础代码位于extensions/DwMultiQueue.php

业务代码

• QueueCommentChild (子评论的队列)
• QueueCommentLike (评论的点赞队列)
• QueueCommentReply (评论的回复队列)
• QueueCommentShare (评论的分享队列)
• QueueGameLike (游戏点赞队列)
• QueueSubjectCmt (帖子的评论队列)
• QueueSubjectLike (帖子点赞队列)
• QueueSubjectPost (帖子发布后的后续处理队列)
• QueueSubjectShare (帖子的分享队列)
• QueueSubjectView (帖子的浏览队列)

前台使用方法（生产）

1. 继承DwMultiQueue，设置队列分批数，默认10。

2. 调用report方法，插入数据到队列。

   例如

   (new QueueSubjectPost)->report(['subjectId' => $subjectId]);

后台使用方法（消费）

1. 继承DwMultiQueue，设置队列分批数，默认10。

2. 实现handleOne方法，其中$elem参数由前台入队数据结构决定。

   例如

   QueueSubjectLike.php

---

社区业务概览

• 帖子
  • 评论
    • 子评论
    • 父评论
    • @评论
    • 操作
      • 点赞
      • 举报
      • 屏蔽 (可针对user,subject,comment)
      • 删除 (用户自删/后台删)
  • 操作
    • 点赞
    • 举报
    • 屏蔽 (可针对user,subject,comment)
    • 删除 (用户自删/后台删)
  • 操作
• 私信
• 用户
  • 用户关注
    • 关系
      • 被关注 (粉丝)
      • 关注 (订阅)
      • 互关 (好友)
    • 途径
      • 线上关注
      • 线下扫码 (完成后直接互关)
  • 用户主页
    • 用户主页置顶帖
  • 用户屏蔽数据
    • 屏蔽用户列表
    • 屏蔽帖子列表
    • 屏蔽评论列表
• 社区综合
  • 列表
    • 置顶帖
    • 热门帖
    • 关注人的帖
    • 最新更新帖
    • 公告（在后台打了"公告"标签的帖子）
  • 数据
    • 按日访问量
    • 帖子发表数
    • 评论发表数

一些特殊注意事项

• 公告

  最初开发以inform存储系统公告，在APP也有专门的位置展示系统公告，而非帖子形式

  之后为了灵活运营，就有了帖子形式的公告，在后台发布打了"公告"标签的帖子，也算是公告。

• 后台检索帖子

  注意官帖和非官帖的区别。

  有时经常查不到内容，就要注意搜索条件顶部有没有切换[官帖/非官帖]

• 用户关注表深度解析

  • 首先理清双方的技术角度称呼

    uid-本人；to_uid-对方

  • 再理解两者关系的方向性

    这里采用is_fans表示，意为[是否为对方的粉丝]，请仔细、慢慢理解这几个字的意思，再往下看。

    当is_fans=0，意思即[不是对方的粉丝]，用技术语言来讲，就是uid被to_uid关注。（既然不是对方粉丝，为什么要存这条数据？那是因为对方关注了自己，于是自己这一方，就必须存储了对方的逆向数据）

    当is_fans=1，意思即[是对方的粉丝]，用技术语言来讲，就是uid关注了to_uid。

    设置is_fans字段的原因：在以uid分表后，支持逆向查询。

  • 粉丝与好友的联系和区别

    粉丝即单向关注，从表userfollow*上看，只有一对互逆关系数据（2条）

    好友即互相关注，从userfollow*上看，会有两对互逆关系数据（4条）

  • A与B关系的记录形式初始值约定

    • uid=A, toUid=B, isFans=1, isIgnore=1 (A方的正向记录，A关注了B)
    • uid=B, toUid=A, isFans=0, isIgnore=0 (A方的反向记录，B被A关注)
    • uid=B, toUid=A, isFans=1, isIgnore=1 (B方的正向记录，B关注了A)
    • uid=A, toUid=B, isFans=0, isIgnore=0 (B方的反向记录，A被B关注)

  • isIgnore值变化的约定

    isIgnore用于突出显示最近关注自己，但自己还没处理的人;

    在点击[忽略关注]后，值从0变1。但当再次被他人强行重新关注(二维码发起关注)时，值再次变为0，按钮“忽略”再现。

    • A 发起关注 B 时

      • uid=A, toUid=B, isFans=1, isIgnore=1 (A方正向记录，不需要"忽略"按钮)
      • uid=B, toUid=A, isFans=0, isIgnore=0 (A方反向记录，需要"忽略"按钮，此按钮只能由B使用)

    • A 被 B 忽略时：

      • uid=A, toUid=B, isFans=1, isIgnore=1 (A方正向记录，不需要"忽略"按钮。即不需要变更任何字段)
      • uid=B, toUid=A, isFans=0, isIgnore=1 (A方反向记录，被B点了"忽略"按钮，此后在B的fanslist中，不显示此记录的"忽略"按钮)

    • A 被 B 回关 时，两人建立"互关"关系：

      • uid=A, toUid=B, isFans=1, isIgnore=1 (A方正向记录，不需要"忽略"按钮。即不需要变更任何字段)
      • uid=B, toUid=A, isFans=0, isIgnore=1 (A方反向记录，由于被B回关，故此后在B的fanslist中，不显示此记录的"忽略"按钮)
      • uid=B, toUid=A, isFans=1, isIgnore=1 (B方的正向记录，B回关了A。此记录字段没有变化)
      • uid=A, toUid=B, isFans=0, isIgnore=1 (B方的反向记录，A被B回关，故此后在A的fanslist中，不显示此记录的"忽略"按钮)

      可见，互关关系下，四条记录的isIgnore值都是1