ToB企服应用市场:ToB评测及商务社交产业平台

标题: 《亿级流量系统架构筹划与实战》第十二章 评论服务 [打印本页]

作者: 冬雨财经    时间: 2024-9-2 19:43
标题: 《亿级流量系统架构筹划与实战》第十二章 评论服务
内容总结自《亿级流量系统架构筹划与实战》
  一、概述

评论作用:

评论具备能力:

评论模式:


二、单级评论模式

1、模型筹划

表名:comment
字段名类型含义idbitint主键content_idbitint内容id,代表评论区内容唯一标识comment_idbitint评论iduser_idbitint评论发布者idreply_user_idbitint如果时复兴评论,则给出被复兴的用户id,默认值为0reply_comment_idbitint如果评论是复兴,则给出被复兴的评论id,默认值为0comment_timedatetime评论发布时间 索引:

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评论发布时间 索引:

2、评论审核与状态

可参考之前的内容发布系统

3、按照热度排序

热度评判维度:

对于按照热度排序的评论列表,有如下几个重点要阐明:
流程图
   
  
4、评论读取流程图

   
  
5、架构总览

   
  



四、盖楼评论模式

1、数据库递归查询

借助数据库的递归查询能力,直接实现
   
  
2、数据库保存完整楼层

单独新增一个build字段,用来保存全部的评论id
   
  
3、图数据库

评论间的复兴关系本质上就是一个树形布局,所谓盖楼评论无非就是在此树形布局中对某个评论节点进行深度遍历,所以在盖楼模式下非常适合使用图数据库。

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。




欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4