浅谈留言盖楼设计

一、写在前面

最近在写博客的留言功能,由此引发的思考,留言一般分为简单留言和盖楼留言

简单留言:一问一答,对于没有大量用户评论或者评论不是核心功能的app来说就够用了。

11

盖楼留言:有着大量的用户评论,那么设计“盖楼”的效果还是可取的,这样能帮助用户找到该条评论或者回复的上下文情景。但是根据“盖楼”的显示效果不同,设计上也是有很大的差别的。

22

如何设计一个简洁优雅的盖楼留言呢?下面让我们带着这个问题进入今天的课题

二、盖楼设计

数据库结构模型如下:

create table ArticleComment(

@ID int, –标识列

@PID int, –回复ID

@ArticleID int, –文章ID

@Content ntext, –内容

@IP nvarchar(50), –IP

@AddDate DateTime –留言时间

)

方法一:

复制前面回复,附加上新的,一同放入 Content 中。Content 要足够大,足以放下所有的楼层。

1542187619(1)

这样做有两个缺点:

1. 占用空间大

2. 前面的回复后修改后,后面的不好更新

方法二:

递归,需要程序查询所需和前端做必要的处理合并就可以达到效果。这里又引出另外一个问题“当留言回复的层数过多的时候,比如1万条盖楼,会极大拖慢系统的加载时间。”

一种解决方案:

1.文章留言分页加载

44

2.每个父ID下面只能挂在留言级数需要控制,多余的下一页显示。页面由用户触发

33

 

三、盖楼总结

上面只是简单列举目前市面的上几种留言实现方式,如果你的系统每天都会有成千上万条评论,那么单表的设计肯定是不行,优化的方式也有很多。

  • 分库分表。分库分表是最为常用也最有效的优化方式,建议按照主题来分库分表。这样同一个主题下面的评论就会落到同一张表里,避免了跨表查询。
  • 适当的数据冗余。如果你需要显示评论人的相关信息,那么在插入评论时就把这些信息写入评论表中,避免多次查询。实际上,如果是纪录数据,都可以冗余对应的数据信息,因为它们的数据的实时行和一致性要求并不高,用户不会因为评论中的头像没更新而撕了你,哈哈。
  • 如果pd要求你能给评论点赞,得注意点赞幂等性,同一个用户只能点一次赞或者取消自己的点赞。因为从幂等性的要求来说,每个赞都是一条记录。评论的赞数如果都从点赞表中统计得出,那么性能开销会十分巨大,而且点赞如此轻量级的一个操作一定会加剧点赞表的竞争操作。所以建议直接在评论表中添加一个like_count的计数器,维护该冗余该字段。减轻服务器聚合数据的压力,热门评论加缓存。类似于网易新闻的热门评论,读取频度非常高,可以专门开接口给客户端,同时该接口做缓存。
本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 浅谈留言盖楼设计

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址