小猪的博客

朋友圈好友关系建模设计—动态评论设计

接上一篇,我们有了好友关系之后,就又涉及到了怎么样处理“只能看到好友的动态,和好友在好友动态下的评论)

其实关于获取好友状态,已经不成问题,从数据库中读取出来就行了,最后统一出一个好友列表,然后进行查询就行了。关键的地方在于这个好友动态的排序以及评论呈现。

1、关于评论和动态的获取

我们采取的方式是:后端返回全部动态,前端进行排序。这样的好处是大幅减小了后端的压力,因为如果不这样,后端得依次进行如下操作:

获取当前用户 -> 获取用户的好友列表 -> 对每个用户的好友选择出所有动态 -> 对所有好友选择出来的动态进行排序 -> 对最后结果只返回前n个(后续的再次发送请求获取)

这样的方式对于小型服务器来说是致命的,举个例子,1个人有50个好友,每个好友20个动态,每个动态5条好友评论,光是获取所有好友动态就必须查询50205=5000条记录,然后还要对这5000条记录进行排序,最后选择出指定100条。这中间还没有包括根据好友进行评论过滤,匿名信息的转换之类的过程,可想而知,一旦大量用户登录查看动态,服务器将压力非常大。

因此,我们将排序做到了前端,后台在进行查询的时候,查询的时候只查询到动态层面,评论在用户点击指定动态之后才会获取,将一步的动作分成两步,用户在下拉浏览的同时发送新的获取评论请求,服务器再返回指定动态的评论,这样就将5000化为5020+n5,n为每页显示的动态数,大大减缓了服务器的压力。同时,通过缓存技术比如Memcached,保存用户的好友动态,防止用户首页快速刷新造成大量的请求。

2、关于评论的呈现

仔细一想,评论其实满足了一种树形结构,因为我不但可以评论这条动态,也可以评论之前的评论,所以,在存储评论的时候,我们可以加入一个parentID,再配合messageID(根节点,动态的ID),就可以进行前端的评论的树形结构生成,大概的数据表就是这样:

这样,基本的功能就完成了,其实现在想想都是很简单的设计,只不过以前并没有做过和思考,导致当时开发遇到了一点点小问题- -~

就到这里吧,最后再次广告:github:https://github.com/lizhuoli1126/FriendCircle