内容总结自《亿级流量系统架构筹划与实战》
一、概述
评论作用：
- 增加社交互动
- 促进用户的加入和分享
- 促进用户天生内容
- 增加社交产品的流量
评论具备能力：
- 发布评论
- 删除评论
- 点赞评论
- 拉取内容评论列表
- 拉取用户评论列表
- 运营评论
评论模式：
二、单级评论模式
1、模型筹划
表名：comment
字段名类型含义idbitint主键content_idbitint内容id，代表评论区内容唯一标识comment_idbitint评论iduser_idbitint评论发布者idreply_user_idbitint如果时复兴评论，则给出被复兴的用户id，默认值为0reply_comment_idbitint如果评论是复兴，则给出被复兴的评论id，默认值为0comment_timedatetime评论发布时间 索引：
- idx_user_list(user_id,comment_time)
- idx_comment_list(content_id,comment_time)
2、分库分表须要性
由于受限于分库分表的须要性，我们无法选择出合适的字段作为路由依据。我们可以进行数据表冗余筹划：创建两个布局与comment数据表的布局完全一致的数据表content_comment和user_comment，前者将idx_comment_list(content_id,comment_time)作为索引，将content_id作为分库分表的路由依据；后者将idx_user_list(user_id,comment_time)作为索引，将user_id作为分库分表的路由依据。当查询某内容的评论列表时，评论服务会查询content_comment数据表；当查询某用户的评论列表时，评论服务则会查询user_comment数据表。
当用户发布评论、删除评论时，要同时更新content_id和user_comment这两个数据表。为了保证这两个数据表的数据一致性，我们可以选择content_comment作为主表，而user_comment数据表通过伪从技术自动同步最新的评论数据
3、高并发题目
评论是一个高并发读&高并发写的场景。
高并发读：
高并发读：
这里的高并发读评论，特指拉取热门内容的评论列表。对于绝大部门用户来说，其拉取的评论列表是位于评论区的前几页的那些评论。所以可以为评论列表中的前N条评论构建Redis缓存。使用Redis的ZSET布局来优化，其中Key为内容ID，Member为评论ID，Score为评论发布时间。
三、二级评论模式
1、模型筹划
评论元信息表：
字段名类型含义idbitint主键content_idbitint内容id，代表评论区内容唯一标识comment_idbitint评论iduser_idbitint评论发布者idroot_idbitint如果评论是对内容的评论，则该字段值为内容ID；如果评论是一级评论下的评论，则该字段值为一级评论leveltinyint评论品级（1：一级评论；2：二级评论）reply_countbitint此评论被复兴次数，仅一级评论需要记录like_countbitint此评论被点赞次数reply_user_idbitint如果评论是对内容的评论，则该字段值为0；如果评论是对某条一级评论的复兴，则该字段值为此一级评论的用户ID；如果评论是对某条二级评论的复兴，则该字段值为二级评论的用户IDreply_comment_idbitint如果评论是对内容的评论，则该字段值为0；如果评论是对某一条评论的复兴，则该字段值为一级评论ID；如果评论是对某条二级评论的复兴，则该字段值为此二级评论IDcomment_timedatetime评论发布时间 索引：
- idx_comment_list(root_id,level,comment_time)：获取内容的评论区和某条评论的二级评论区的评论列表
- idx_user_comment(user_id,comment_time)：用于获取用户的历史评价
2、评论审核与状态
可参考之前的内容发布系统
3、按照热度排序
热度评判维度：
对于按照热度排序的评论列表，有如下几个重点要阐明：
- 按照热度排序，并不意味着一个评论区中的全部评论都遵循此规则。当我们打开评论区时，首先展示的是热度排名前1000（示例值）的评论，在评论区中刷完这1000条评论后，我们看到的依然是按照评论发布时间由远及近排序的评论
- 如果一条评论没有任何点赞，没有任何复兴，即热度值为0，则不属于热门评论，故不加入热度排名。如果一个评论区中只有50条热门评论，那么用户打开评论区刷完这50条评论后，展示的是按照评论发布时间排序的评论列表
- 在刷完热门评论后，按照评论发布时间排序的评论列表中依然可能会包含热门评论，也就是说，用户会刷到重复的评论。比如，微博的评论列表就会发现，热门评论会重复出如今按照评论发布时间由近及远排序的评论列表中
流程图
4、评论读取流程图
5、架构总览
四、盖楼评论模式
1、数据库递归查询
借助数据库的递归查询能力，直接实现
2、数据库保存完整楼层
单独新增一个build字段，用来保存全部的评论id
3、图数据库
评论间的复兴关系本质上就是一个树形布局，所谓盖楼评论无非就是在此树形布局中对某个评论节点进行深度遍历，所以在盖楼模式下非常适合使用图数据库。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
